N/A

Data Conversion to New Software -- Three Temptations That Can Waste Your Time and Money

  1. I need to convert all historical data from the old software to the new software.
  2. I need to run parallel for at least a month.
  3. I need cut over as of 12/31 to have a full year

Though tempting on the surface, consider these practicalities.

Temptation #1:
I need to convert all historical data from the old software to the new software.


For complex businesses with a many commas and zeros in the conversion budget, maybe. For the rest of us, the ROI is questionable.

Clearly, there is a subset of data that almost every business will want to convert: opening GL balances, open Accounts Receivable, open Accounts Payable, Reconciled Cash Balances, and Inventory Valuation (for businesses with inventory). In addition, of course, companies will usually want to convert their Master Files--such as Customer/Client file, Vendor File, and Inventory Items--- after cleaning up old, obsolete, and duplicate data.

In our consulting practice, clients will ask 'why not just migrate ALL of the data forward, so that we have everything in the new software? In theory, that is an excellent strategy. In practice however, not so easy.

First, the new software will typically have have new ways of organizing data that are different from your old software. Trying to 'map' historical data from our old software--such as QuickBooks-- to the new software can be more than challenging.· Furthermore, even if you could perfectly map the old data to the new software, how accurate, reliable, and consistent is the data in your old software? Do you really want to migrate forward the 'messes' from the past?.

Second, when converting to the new software, companies should rethink and restructure their data categorization strategy to meet new and projected requirements.

Often, the legacy software uses a twisted and convoluted structure of accounts, sub-accounts, and classes--attempting to 'stuff' all of the reporting through the General Ledger.

In contrast, the new software has new data capture and reporting methods that are more flexible, comprehensive, and useful. In planning the conversion, this is a great opportunity to take advantage of new reporting capacities by customer type, territory, product type, region/location, etc.

You made the decision to invest in new software for many good reasons. This is a good time to rethink and plan how to exploit new capabilities. It is tempting but short-sighted to simply migrate old, inefficient and klugy data structures.

Third, the old software is not necessarily 'going away'. Typically, there is an opportunity to retain the old software and data for inquiry purposes. With access to the old data, you can research transactions that occurred prior to the cut-over. Over time, the old data becomes and less and less relevant and the number of searches declines.

(Tech Tip: If the legacy software exists on failing equipment or an out-of-date operating system, you can still arrange access with a Virtual machine or similar IT strategy).

Fourth. Happily, there are second chances. Occasionally, a company determines post-conversion that they really, really, do need to bring forward certain historical data. For these clients, we have successfully imported historical data into the new software, post cutover.

Bottom line, the decision of how much historical data to migrate is a tradeoff between the costs of a complete migration vs. the costs of data-retrieval, post conversion. For many small-to-mid size businesses, converting all of the historical has very high costs with minimal payback.



Temptation #2:
I need to run parallel for at least a month
.

This temptation is a legacy from a world of custom-programmed software. For businesses deploying mainstream software, running a full 'parallel' is rarely a winning strategy.

Among other factors, the time requirements are impractical in a typical small to mid-size business. People already have a full-time job. If you ask them to process each transaction twice (once in the old system, once in the new system), that is twice the workload. On top of that, there is additional time to compare results, reconcile, and diagnose differences.· Not practical.

As an alternative, we recommend methodical testing of sample transactions. Although there are many variations, the general approach is as follows.

  1. Create a test environment. In the simplest form, install the new software on an accessible server.
  2. Populate the Master Files and configuration options--based on the decisions you made in the data migration planning process. (See Temptation #1, above).
  3. At some point, you are going to populate the master files and configure your system for the 'live' migration. Now is a good opportunity to test the migration plan. Why not setup your test environment with real customers, vendors, products etc? ·In the test environment, you can trouble-shoot the decisions you made on how to capture, code, and categorize data.
  4. Gather samples of typical transactions from recent workflow. Samples might include: Customer Quote, Customer Sales Oder, Invoice to Customer, Purchase Order to Vendor, Cash Receipt, Accounts Payable transaction, cut checks, etc.
  5. Process these typical transactions in your test environment.· Review registers, journals, and reports. Are you seeing the results you expected? What changes do you want to make to forms, categories, codes, setup options, and other planning decision?

Of course, processing test transactions will take time. However, far less time than a full parallel. Focusing intently and methodically on a few well-chosen test transactions, will provide high payoff.

Furthermore, this is a training opportunity on the new system. You can train multiple people at a pace and time frame that is practical and reasonable.· Let them become comfortable with the new system, before the pressures of a cut-over. As you work through the test transactions, questions will arise. This is normal. Those questions will lead to handling exception transactions, more questions, more training, and revisiting the conversion plan. Good. Familiarity and comfort with the new software grows.

A final note: The technical environment for your pilot test can be simple or complex. If you have multiple software packages that need to co-exist or interact, it is often helpful to deploy a test environment using VMware or other virtualization software. (Virtualization is outside the scope of this blog article. However, MBSG has experts who can advise and help). Virtualization allows you to replicate a complex environment, without disrupting normal processing flow.

In summary, a well-executed test plan will help you achieve a happy outcome. Typically, this is far more productive than asking staff to work evenings and weekends to double process every transaction in parallel.

Temptation #3:
I need to cut over as of 12/31 to have a full year of financial data.

At first glance, it is tempting to time your conversion for the new accounting year. In practice, this is unnecessary and in some cases unwise.

First, consider that a January 1 cut-over date means lots of preparation and testing activity in November and December. Possibly, this is your slow season. Either way, you will be bumping up against holiday schedules with planned and unplanned time off.· Typically, it is hard to maintain attention and focus on new systems when there are other distractions, including other year-end work.

Second, consider that you do NOT need to convert as of 1/1/ to a have a full year of financial data. Our clients can convert at any month-end that is convenient for them.

Assume for example a conversion as of 4/30.· You can load month-end balances for each GL account as of 1/31, 2/28, 3/31, and 4/30. This gives you a 'full year' for producing financial reports--including comparative reports.· Using the same technique, you can also load month-end balances for each month of the prior year. With this approach, you can compare MTD this year vs. last year, YTD this year vs. last year, etc. There are many variations on this strategy

All planning decisions subject of course to real world constraints of time, budget, and data availability. Bottom line, remember that you have flexibility to plan the· cut-over at a time and pace convenient for your organization.


MBSG helps clients streamline, automate, and integrate business management systems.· We deploy systems 'in the cloud' and 'on the ground'. To discuss improvements to your inventory, accounting, ERP, manufacturing, work flow or IT support systems, contact MBSG at 818 338-7220 or This email address is being protected from spambots. You need JavaScript enabled to view it. .