Category Archives: Custom Software Development

Migrating Your Legacy Software

Eight Key Questions to Explore

Over the years, you’ve built a highly-successful business around a custom software application.  Early on, it was a wonderful asset.  But all the while it helped to drive your company’s growth engine, the software remained the same.

Fast-forward a decade or two, and the software is really showing its age.  While it used to run lightning-fast, today it bogs down under the increasing load of database bloat and more users than anyone could foresee.  Perhaps your IT department has begun e-mailing you dire reminders:  They can’t find compatible hardware any more.

There’s a second, related issue:  Typical software applications comprise thousands—if not hundreds of thousands—of lines of code.  Finding programmers who can (or are willing to) support your software may become a serious challenge.  (We know of several business owners facing this situation.)

What’s a pragmatic decision maker to do?  One option:  Nothing.  After all, the software still runs.  Never mind the occasional glitch now and then.  If, on occasion, you lose half a day’s worth of data because your IT staff has to restore from backup, well that’s just a cost of doing business, right?

Perhaps your exit strategy includes letting a future manager deal with the issue.  So, for now, you cross your fingers and pray that the momentum of the status quo will propel your business forward, until aging software is no longer your concern.

But what if you worry about your legacy software?  What if it keeps you awake at night?  How will you ever carve out enough hours to manage a software development project, without neglecting your core business?  How can you capitalize upon what you’ve already built, while taking advantage of everything that modern software languages offer?  And what other questions should you be asking—questions you may not even realize should be taken into consideration?

Migrating to newer software can be a daunting proposition.  Short of writing a textbook, it’s not practical to cover every possible decision that business owners must weigh.  But here are several key questions you may want to contemplate…

1)  Will the project require new hardware?

A handful of our customers are still using outdated operating systems.  Not because they want to, but because they must.  Their software simply won’t run on newer hardware.  Considering that Windows XP, Vista, and Windows 7 have all reached their end of mainstream support[i] dates, now might be a great opportunity to migrate to new hardware as well.  Do you plan to update your workstations in conjunction with your software upgrade?  Will a server upgrade be required?

As you develop a budget for new software, you’ll also want to include the cost of new hardware into your projections.

2)  On which platform(s) will the new software be developed?

The three most likely candidates are:

  1. Desktop (applications running on your PC or laptop—the ones you launch by double-clicking a shortcut)
  2. Browser-based (i.e., web sites you access via Internet Explorer, Chrome, Mozilla Firefox, etc)
  3. Native applications (i.e., smart phone apps written for IPhone and Android)
  4. A combination of all three

Each platform offers both advantages and unique programming challenges.  The following matrix spells out the relative strengths and weaknesses of each.

FactorDesktopBrowser-basedNative (Smart Phone)
User ExperienceDesktop applications utilize a wide variety of robust, user-friendly controls which make pointing and clicking a snap.

This environment is familiar territory for most end users, meaning that time spent on user training will often be minimal.

Web-based apps are designed to run on most browsers.  They usually can’t access an individual device’s capabilities.  Thus, they must be hardware-agnostic.  Beyond standard browser controls (check boxes, buttons and the like), web apps require extra coding to incorporate specialized controls and functionality.The main benefit that native apps offer over web apps is that they are fully compatible with the device’s native features, such as GPS, camera, phone, and accelerometer.  They give you access to a device’s hardware and software, allowing you to incorporate photos on the fly, access GPS information, and communicate via phone or text—all directly from your custom app.
PerformanceProperly configured, a well-written desktop application will run quickly.  Users won’t experience the slower connection speeds they might occasionally encounter on other platforms.

Smart developers will configure the application to download the majority of application content onto the local PC, meaning that the only network traffic will be data as it’s read from and saved back to the database.

Web applications require a reliable internet connection.  If your connection is slow, they may creep along much more slowly than their desktop counterparts.

This will be especially noticeable on mobile devices, because images and animations take time to download.  Graphic-intensive web applications may also consume considerable bandwidth and battery reserves.

Native apps tend to be faster and more responsive.  After a native app has been installed, most of the graphics and code that run the app are already stored on the device.  Thus, the time and bandwidth required to access content on the server will be lower than a similar browser-based application.  As a result, native apps are often much faster, and provide a better user experience.

They can also be configured to automatically sync data stored locally on the phone with a web-based server when the device isn’t in use.

SecurityMost often, your application data is stored within your Local Area Network (LAN) or secure cloud-based storage.

Provided that your IT staff has configured your firewall and VPN properly, hacking into the database will be considerably more difficult than other platforms.

Any time your company allows access to content over the internet, it becomes slightly easier to exploit the connection to your database, and thus easier to compromise your data.  At a minimum, you’ll want to insist on using Secure Sockets Layer (SSL) encryption.

For added security, if IP addresses of end users are static, you may want to have your IT department restrict access for all unknown IP address.

Think of how much sensitive data lives on your phone (contacts, e-mail addresses, phone numbers, etc.).  Mobile devices often connect to the internet through untrusted WiFi connections, which malicious eavesdroppers can readily exploit.  If one of your users loses his phone or sells it on eBay without resetting to factory defaults, it’s possible that your corporate resources could be compromised—especially if users select the option to “Remember My Password”.

These risks can be mitigated somewhat, by implementing a strict security policy and deploying logic on the server to prevent device spoofing.

ExtensibilityVirtually all device manufacturers provide drivers for their peripheral devices.  This makes it relatively easy to integrate desktop applications with printers, cameras, scanners, RFID readers and the like.In earlier days, browser extensions and plug-ins (such as ActiveX objects) unwittingly opened the door for security breaches.  As a result, most web browsers no longer grant access to computer resources, such as file systems or peripheral devices (at least, not by default).

If your company wants to develop a web application that interacts with users’ hardware—or automatically creates, prints, e-mails and/or saves files, please give serious consideration to either a desktop or native app instead.

Many smart phone manufacturers provide hardware ports to allow for interaction with external devices.  One would think it should be easy for programmers to write code to communicate with accessories.  But this is not always true.  The device manufacturer must provide a set of driver files conforming to the type of smart phone(s) you plan to use.

The bottom line:  if you need to link an external sensor or other device to your native app, make sure that the manufacturer provides compatible drivers.  Please don’t assume that your programmers will figure out how to make it all work.

Program- ming ComplexityOf the three platforms, desktop apps are usually the fastest to develop and deploy.

Desktop applications are programmer-friendly.  Many programmers learned how to program in this environment, and are very comfortable developing applications for the desktop.  Sometimes it’s simply a matter of dragging and dropping the desired controls on a form, eliminating the need for writing additional code.

As a result, the overall cost of a desktop application will likely be lower.

Today, web applications frequently utilize what’s known as the MVC (Model-View-Controller) design pattern.  This approach allows for efficient code reuse and simultaneous development by multiple programmers.  But it takes time to configure properly.

In fact, web applications almost always require more time to set up, configure and test than a desktop app.  Consequently, the cost for web applications is often higher than a similar application designed for the desktop.

One of the greatest challenges in developing smart phone apps is that we must develop a separate code base for each platform.  Each mobile vendor provides its own Software Development Kit and user controls, which must be used to develop apps for that device.

Thus, if your company wants to deploy an iPhone app, programmers will develop and upload an iOS app to Apple’s App Store.  Need an Android version of the same app?  Programmers will write a separate set of code for Android, and then deploy it to the Android app store.  As a result, native apps are often the most costly of the platforms.

However, native apps usually run faster on smart phones and are better equipped to harness the capabilities of the hardware on which they’re installed.

Installation and accessDesktop applications are usually installed on your company’s local area network (LAN).  If users must access the application from outside your office, they’ll need to use connectivity software (Remote Desktop, for example) to gain access.  This isn’t necessarily a bad thing—especially if security is a concern.

Installing a desktop application on a new PC can be a very simple process, provided that the developer configures the necessary tools for doing so.


Since most of the code associated with a browser-based app runs on the web server, no installation is required.  Just navigate to the site and you automatically have access to the latest content.

Web applications rely on consistent internet connectivity and speed. The lack of either can cause significant issues.  This is especially noticeable when running web apps on smart phones.  Users may have to wait for the browser to download all the content.  If your application incorporates numerous photos or graphic images, you may want to consider developing a native app instead.

In addition, web applications require extra effort on the part of end users.  They must remember your specific web address (or find it on a search engine).  If users fail to bookmark your site, they’ll need to repeat the entire process any time they want to connect with your business.

Mobile apps are usually distributed via App Stores.  When users install a native app, they will only have to remember the loading instructions long enough to download it.  From that point on, your products and services will be just one click away whenever they use their smart phone.

Native apps usually run faster than web-based apps.  Once installed, they don’t have to continue downloading the same resource-intensive files over and over. Thus, they often use significantly less bandwidth.

UpdatesDesktop applications can be configured to automatically update to the latest available version with little or no user intervention.

But not all desktop applications function this way.   If you opt for a desktop application, be sure to ask your programming team how they plan to deploy future updates.

Since most of the code runs on the web server, updates to web applications download automatically whenever you navigate to a new page.

End-users do not have to bother with installing updates because they’re managed by the web server administrator.

Native apps user may need to download and install updates periodically.  In some cases, users may be prompted to completely uninstall the previous version prior to installing a later version—but nowadays, this is rare.

In the world of custom software applications, one platform definitely doesn’t fit all needs.  In fact, your ideal solution may involve a customized mix of platforms and programming languages.

3)  Which programming language(s)?

Beware the programmer who insists that his language of choice is the absolute best—and there’s no room for debate.  As technology advances, programming languages continue to evolve.  Some fully embrace newer hardware architecture and software development patterns.  Others are headed for retirement.

For example, Visual FoxPro (VFP) is a wonderful, robust programming language.  We still support over a hundred custom applications written in it.  But its vendor discontinued support a few years ago.  Today, we wouldn’t suggest migrating even an ancient 16-bit application to VFP.  Instead, we would likely recommend C#, PHP or ASP.NET.  Why?  The chief reason:  programmer availability.  At some point in the future, you may decide to entrust your software development to a different programming company.  That will be a serious challenge if you can’t find anyone who speaks the language.

So, rather than letting an obscure language bind your company to a programmer for decade(s), you’ll want to opt for a programming language that’s widely supported.  Spending a little time on this question up front will help ensure you aren’t saddled with a decision you’ll regret for years to come.

Here’s a useful site to visit when considering software developers and the language(s) they’re proposing:  The TIOBE Index compiles a monthly list of programming languages based on popularity and the number of lines of code written.  If you can’t find the programmer’s proposed programming language in the top 50, you might want to consider finding a different programmer.  Speaking of programmers…

4)  Which programmer(s)?

One thing I’ve learned over decades of hiring (and firing) programmers:  just because someone enjoys tinkering with code doesn’t mean s/he’s qualified to tackle your project.

You’ll want to dig deeper—looking beyond flashy marketing handouts and web sites—to carefully examine the competency level of the programmer/team you hire.
How?  Here are a few suggestions:

  • Ask for references. Then, follow up with each reference, verifying that software users are truly happy with both the quantity and quality of code written.
  • Schedule a screen-sharing session to review examples of applications the programmers have developed which are similar to yours.
  • Ask whether the coding will be outsourced, or performed in-house.
  • Find out whether programmer(s) will be available to communicate with you in real time, or whether time zone differences will necessitate more staggered communications.
  • Ask what steps the programmers take to avoid SQL injection (they should surely understand your question—even if you don’t).
  • Finally, be sure to verify who will own the source code[ii] once the project is complete.

5) Which database?

According to a recent DB-Engines[iii] survey, the five most popular database engines are:

  • Oracle
  • MySQL
  • Microsoft SQL Server
  • PostgreSQL
  • MongoDB

Each has inherent advantages and disadvantages in terms of cost, speed and support.  Your company may already have settled on a standard.  If so, you have one less thing to worry about.  If not, ask your developer for recommendations, and reasons for those recommendations.  Be sure to consider the total cost of ownership.  Database costs fall into two expense categories: capital and operational.  The cost of database licenses, and installing and configuring the database can vary widely.  Opting for an open-source database may save money initially.  But lack of support (and therefore, higher maintenance costs) might offset any benefits you gain up front.

6)  Should we migrate our data?

Migrating existing data to your new application will ensure that users can find historical data for orders, invoices and inventory without requiring them to launch the old application.  It’s usually the best approach.

Data migration can also burn up a lot of programming hours—and dollars.  Why?  Because frequently, older tables aren’t structured very well—the former application may have deliberately duplicated data across multiple tables.  But subsequent updates to some of the tables—without updating the duplicate records in their counterparts—can leave us scratching our heads and asking, “which data should we migrate?”

Secondly, earlier developers often used a combination of fields to ensure uniqueness.  They just assumed that every record will be unique because of its content.  After all, how many John Smiths could possibly have the same birthdate?  Too often, these assumptions were wrong.  When a database is designed poorly in the beginning, migrating to a more logical structure can be a real challenge.

Because of these issues, and the extra programming time required, some customers prefer to ‘Drain the Swamp’.  In other words, keep using the old application until outstanding invoices are paid, purchase orders have been received, and so on.   But once a cut over date has arrived, all transactions will flow through your new application.

7)  Will the new application talk to other software?

Today more than ever:  no software is an island.  To prevent re-keying the same data into multiple applications, software developers build electronic bridges to seamlessly pass data back and forth.

Most software applications we write communicate with multiple systems, interfacing with one or more of the following:

  • Accounting software
  • Scheduling systems
  • Time clocks
  • Payroll services
  • Real-time inventory management
  • CRM systems
  • Payment processing services
  • Phone systems / billing software
  • Web services (API’s)
  • Web site scrapes
  • File imports, including CSV, Excel, XML, JSON, SDF
  • E-mail
  • SMS
  • Document scanners
  • RFID / Barcode Scanners
  • Document generation, archiving and transmission structures

Software interfaces can be quick and easy to write.  They can also be extremely complex.  The more you identify and document your integration needs up front, the more complete road map you’ll have.  And the less likelihood of future sticker shock.

8)  Should we migrate everything all at once?

Whenever possible, we recommend migrating your application in phases.  If your legacy application spans several modules that run independently of each other, it would be wise to divide and conquer—migrating modules one-by-one.

This will give you the chance to assess your progress, and course-correct along the way.  It also gives you more budgeting flexibility—possibly allowing your company to stretch expenses over a longer time frame, as each new phase comes online.

The Upshot …

Migrating a legacy software application is not for the faint of heart!  We’ve explored several of the weightier questions you’ll want to consider.  No doubt, you’ll identify many more as you move forward.

How you arrive at the answers to your questions will depend on your company’s specific needs, your budget, and time frame.

We wish you all the best.

[i] Microsoft Corp. Windows lifecycle fact sheet Accessed July, 2017.

[ii]I/O Technologies, Inc.  Who Owns Your Source Code?  Accessed July 2017.

[iii] “DB-Engines.” The Most Popular Database Management Systems, July 2017. Accessed July 2017.

One-Time update for Odolog users.

 We’re pleased to announce that effective immediately, users of the free Odolog application can download an update which will make all future updates completely automatic.

Previously, if you needed to update your version of Odolog, the only way to do it was by reinstalling Odolog from scratch.

Starting now, we have incorporated the ability to update Odolog automatically.

Do I need this update?

Here’s a quick way to find out if you already have the newest version. While running Odolog, choose Help … About.

If you see version 1.2.68 (or higher), you already have the latest version and don’t need to install this one-time update.

If your version is not 1.2.68 or higher, it would be a good idea to perform this special update. Why? Because in the future, any time we deploy an bug fix or enhancement update, it will install itself automatically.

To install this special update, please follow these eight easy steps:

  1. Back up your data. Although we don’t expect this update to interfere with your data files—it’s better to be safe than sorry. It’s always better to have too many backups–than not enough.
    To back up your data, choose File … Backup Data Files from the main menu. This will create a Zip file containing any data you’ve entered since you first started using Odolog.
  2. Re-download OdoLog and install over the top of your existing installation.
  3. Right-click the shortcut you use to launch Odolog … and choose Properties from the menu that appears …
  4. Click Open File Location on the next dialog.
    IMPORTANT: do not replace the Odolog.exe file in the folder that appears (see screenshot below)!!

    In other words: don’t overwrite the file that has a red IO logo. (FYI, this is a small launcher app, which we use to launch the actual Odolog application.) DO NOT replace it.

    Let me say this again: You do not want to replace the odolog launcher file that has a red IO logo.

  5. Instead, double-click the Resource Folder to open it
  6. Then double-click the Odolog folder inside the Resource Folder.
  7. Inside this folder, you’ll find another file called odolog.exe. This is the one you want to replace.Replace the odolog.exe that you find inside the Odolog folder (which is a subfolder of the Resource folder) by copying/pasting the new Odolog.exe from the Zip file you downloaded into this folder. If prompted: yes, you want to overwrite the existing file.

  8. Finally, close all open windows, and re-launch Odolog. When you choose Help … About, you should see version 1.2.68 (or higher)

What happens next?

In the future, whenever we release a new version of Odolog, you will see a dialog–asking whether you want to install the latest update.
(You’ll see it when you’re exiting Odolog.) Once you agree to install the update, it’ll be deployed automatically. The next time you launch Odolog, you’ll have the latest and greatest version.

One Final Note:

Odolog is free, and we don’t have any plans to start charging for it. But if these instructions seem overwhelming and you’d like us to deploy the one-time update for you, we’ll be happy to help.
We’ll need to charge a one-time flat fee of $9.99 to cover our expenses. (On average it should take less than 10 minutes for us to connect up and deploy this update.)

If you have any questions or concerns in this regard, please feel free to contact me.

How to Contact Us Directly

Recently we switched to a new Voice-over-IP provider, which now allows for direct inward dialing (DID).

If you’d prefer contacting the programmer who’s working on your project directly (instead of going through the automated attendant menu), please feel free to dial any of the following, and your call will be routed directly to that person’s phone:

ContactDirect Number
Dave Martin414-847-9481
Jeanie Martin414-847-9482
Jeremy Vogt414-847-9483
Luke Zahalka414-847-9484
Alex Karius414-847-9485
If you have any questions or concerns in this regard, please feel free to contact me.

Custom Software versus SaaS

Did you know that right now, there’s a major change going on in the software industry? It has to do with how software companies license their software. For example, did you know that when you install Microsoft’s Office 365 on your computer, you’re renting the software for a limited period of time—you don’t own it? In fact, most software vendors are moving to this Software as a Service model, because it’s much more profitable for them.

As more and more software vendors move to Software As A Service, the demand for custom software has been increasing as well. Why?  Think of it this way:  when you hire a company like ours to write a custom software solution, you OWN the software. You’re investing in an asset.  You’re increasing your company’s net worth.   Nobody’s going to be metering your usage ever again.  So you can forget the days of creative seat counting just to stay under arbitrarily-imposed usage levels.  Most importantly, with custom software you own 100% of your data. You, and nobody else, have complete control over who can access your information, and what they can do with it.

So does that mean that everyone needs custom software? Not necessarily—packaged software apps like Quickbooks, and Microsoft Office meet the needs of many businesses just fine. But if your people waste precious time every day rekeying customer data, purchase orders or payroll data into separate systems, we can do something about it. Or if your company needs a solution tailored to your specific way of doing business, that’s where we can help.

I’m Dave Martin, with I/O Technologies. We write custom software that’s good for business.

To RoboDial, or Not?

Which of the following phone calls would you tolerate? And which might you even welcome?

  1. Your family has gathered at the table for dinner when the phone rings. It’s a recording. The nice lady on the other end has an “important message for you about your credit card account”. She doesn’t identify your specific card or mention your bank’s name. You hang up immediately.
  2. A political candidate robodials your cell phone, asking for your support in the upcoming election.
  3. Your dentist’s autodialer calls, reminding you of an appointment you had forgotten to enter into your calendar.

Welcome to the brave new world of Robodial! Like it or not, autodialer software has become part of our culture–even if accepted grudgingly. How does it work? You simply import a list of phone numbers, record an outgoing message, and launch the software. The autodialer dials each number on your list, plays the appropriate recording, and logs the result of each call. Most autodialers offer the ability to respond. For example, ‘Press 1 to talk with a human, or 2 to leave a message.’

While any technology can be abused, autodialers can serve a useful purpose. Resourceful business owners may want to explore this capability as a part of their overall marketing and customer retention strategy.

Let’s look at the potential advantages from a business owner’s perspective. Would autodialing be an acceptable means of contacting your customers in any of these situations?

  • Your shop phone is ringing off the hook with calls from customers, asking for their order status. Contacting them proactively makes more sense, but your staff is already swamped, and you can’t afford to hire another employee just to make phone calls.
  • Your organization needs to contact all its members about a weather-related cancellation.
  • You wish you could call each of your clients personally to remind them of upcoming appointments, but simply don’t have the time or resources.
  • Your mortgage loan customers ask you to contact them immediately when rates dip, so they can lock their loan at the lower rate.
  • Business has slowed for your company. You decide to reach out and remind past customers of all the services your company offers.

Compare how much time it would take for someone at your office to make thousands of calls—when an autodialer could do the work with minimal effort.

Being on the receiving end of an unexpected robocall can be very annoying. And the last thing you want to do is irritate your customers. But there are measures you can take to avoid incurring their wrath.

For example, you could offer autodialing to customers as an opt-in service, letting them decide whether to receive automated phone calls. And, be sure to cross-reference your list of phone numbers with the national Do Not Call registry, so you don’t dial the number of anyone on the list.

Given a choice, most folks would prefer talking with a real person rather than listening to a recorded message. But when used judiciously, an autodialer can be a powerful tool to stay in touch with your customers and prospects.
If you’d like more information, please give me a call.

What’s YOUR programming philosophy?

We met with a prospective client recently, who asked me, “What is your programming philosophy–do you prefer Waterfall or Agile?”

If you’re unfamiliar with the terms, here’s a brief overview:

Waterfall Software Development

The waterfall approach to software development breaks the overall project into several distinct phases:


For Waterfall to work, developers can move on to the next phase only when its preceding phase has been completed and reviewed. We can’t swim upstream, and there are no fish ladders available.

The Waterfall Challenge.
The biggest problem with this approach is that clients seldom have a firm grasp on exactly what their requirements are. If requirements are unclear, the project will never get past the requirements-gathering phase.

But if a client insists on moving forward without completing each phase, software developers will likely end up throwing portions of the code away, as the project scope changes later on.

Agile Software Development

Several years ago, to address the limitations of the Waterfall approach, a group of seventeen software developers met to discuss alternatives. They published the following Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions    over    Processes and tools

Working software    over    Comprehensive documentation

Customer collaboration    over    Contract negotiation

Responding to change    over    Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck   James Grenning   Robert C. Martin
Mike Beedle   Jim Highsmith   Steve Mellor
Arie van Bennekum   Andrew Hun   Ken Schwaber
Alistair Cockburn   Ron Jeffries   Jeff Sutherland
Ward Cunningham   Jon Kern   Dave Thomas
Martin Fowler   Brian Marick

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

Agile software development offers an appealing alternative to Waterfall. Rather than scoping out a massive project and trying to address every possible detail, it breaks development down into bite-size chunks. As each new chunk is finished and tested, it moves into production immediately. This approach is known for its ability to deliver working software to customers faster. Then, as end users begin working with the new features, they often provide valuable feedback to drive future development.

Some of the best software we’ve written was developed using the Agile approach; we met with our customer to identify an overall goal, then wrote self-contained modules which performed specific functions fairly quickly.

The Agile Challenge.
But there’s a potential tradeoff. Developing software without an overall project design is akin to building a house without a blueprint. Unless project stakeholders pay close attention to the overall project evolution, the final result can end up looking like the cobbled-together effort that was used to put it together.

Oh, and then there’s one other small (almost trivial) issue: cost. Agile tends to be a pay-as-you-go approach. As a result, Agile projects can end up costing considerably more than anticipated.

Don’t get me wrong–if your company’s goal is quality software written quickly, then Agile makes a lot of sense. Just realize that if you’re working within a fixed budget, you may end up with less functionality than you envisioned. I.e., you may run out of budgeted funds before the evolving goals for your project all come to fruition.

You’ve probably noticed that I haven’t really answered the question. Why? Because I won’t be writing the check for your software project. More important than asking, “What’s I/O Technologies’ development philosophy?” is the question, “What is YOUR development philosophy?” If you need software quickly and don’t have all the details fleshed out, then Agile is the way to go. On the other hand, if you are faced with a fixed, not-to-exceed budget and can put together a well-defined project specification, then let the water fall!

FERC Report Format Change

The Federal Energy Regulatory Commission announced on April 16 that Electric utilities will need to begin filing FERC reports using XML instead of the current Visual Foxpro format, since Microsoft no longer supports VFP. This affects Form 1, Form 1F, Form 3Q and Form 714.

If your electric utility needs help making the switch to the new XML format, please contact us.


Please Join Us for Our Open House on Oct 28

Oct. 20, 2014

I/O Technologies Relocates to Accommodate Continued Business Growth, New Staff

Software firm’s move coincides with its 20th anniversary

CONTACT: Jeanie Martin, I/O Technologies, (262) 437-3239,

Germantown, Wis. – I/O Technologies, southeastern Wisconsin’s premier source for custom software and software support solutions, has moved to a new, larger office to accommodate its burgeoning business and growing staff.

The tailored software company’s new address is N116-W15830 Main St., Suite 101, Germantown, Wis., 53022. The office is marked by a shiny new sign in the front window.

I/O Technologies didn’t move far – its previous office was on Fond du Lac Avenue in Germantown – but the shift to a more spacious headquarters reflects steady growth in customer orders and production needs. Its software development staff has grown by 33 percent in 2014. Additional hiring is expected soon, said Jeanie Martin, President of I/O Technologies.

“No one likes the work of moving, but we’re doing so with a smile because our company’s growth is driving the need the additional space,” she said. “We thank our great customers who rely on us for custom software solutions, and our business partners who have been with us every step of the way.”

The move coincides with the 20th anniversary of the 1994 founding of I/O Technologies. The company provides tailored software that simplifies day-to-day business activities, and gathers, transfers and reports key business information. All lead to better decisions and lower operating costs.

The Germantown and Brookfield chambers of commerce will hold a joint ribbon-cutting Oct. 28 at 11 a.m. to celebrate I/O Technologies’ new headquarters. The company belongs to both chambers.

I/O Technologies has built a solid reputation for creating custom software solutions that provide a reliable alternative to off-the-shelf packages that might – or might not – perform as needed. Every product has a 100 percent risk-free, money-back guarantee. More information is available at, or by calling (262) 437-3239.

Where To Go After FoxPro

The number of Visual FoxPro programmers dwindles ever smaller as Microsoft’s end-of-life deadline for VFP (January 13, 2015) looms closer on the horizon. Most programming companies have long since abandonded FoxPro, opting to migrate to new development platforms. (Side note: our company continues to support all versions of VFP).

Some time in the future, Visual Foxpro applications will either need to get migrated to something more current, or put out to pasture. So where does that leave savvy business owners who have invested a ton of thought, resources and money into a legacy FoxPro application?

For starters, understand that your FoxPro application(s) will likely continue to run just fine for many more years–maybe even a decade or longer. The sky will not fall just because of an arbitrary support cutoff date. FoxPro is a 32-bit application just like thousands of other 32-bit apps, which run perfectly well in Windows 7 and Windows 8. It’ll probably be quite some time before Microsoft releases a new operating system that doesn’t support 32-bit apps.

But what if your company has decided it’s time to migrate to a new development platform? Unfortunately, there’s no magic button that’ll automatically migrate your VFP application to a current development platform. But today you have more options available than ever before. It all depends on how data flows in and out of your application, whether your company has an IT policy in place, and what that policy mandates regarding preferred vendors and required databases.

For example, if your company has committed to use only Microsoft software and SQL Server, you’ll want to find a knowledgeable software developer who’s skilled at Visual Studio .NET development. On the other hand, if you run with the Open Source crowd, start by seeking out developers who know their way around LAMP (Linux / Apache / MySQL / PHP).

Another key question to ask yourself: how and where should your data be accessible? If users need to access your application and data from outside your office, developing a web or mobile application will probably narrow your needs down to an ASP.NET Developer (for Windows) or a PHP programmer (for Linux-based solutions). On the other hand, if all data entry is done from user desktops, you’ll want to find a company with experience in developing desktop applications.

If you’ve reached this point, call us for a free, no-obligation consultation. We’ll help identify your needs and how best to move forward.

Making data Input more fun, and data Output more valuable.

Do you host your own web server inside your office? Probably not.

Our customers’ web sites are often hosted on servers hundreds or thousands of miles away–not running inside their office.

If the only purpose for your web site is to EXHALE, i.e., advertise products and list your store locations, then there’s no problem.

But what if you want to collect data from your visitors (and that’s always a good idea)? How does that data get from the web server running thousands of miles away, to you in your office?

Many web developers send the data to you in an email. But then you’re forced to copy/paste the data from the email and manually rekey it into your systems inside your office.

We can make this process more fun and easy:

  • First, we can write an interface where users just drag the emails from Outlook and drop them onto our software. The software reads the emails, then pushes the meaningful data into your internal database.
  • Or, even better– we can install a little engine out on the web server that will let you download the data directly –without using email at all.

If the prospect of having to re-key data from your web site into your internal system makes your skin crawl, give us a call!

I’m Dave Martin from I/O Technologies, where we make data Input more fun, and data Output more valuable.