Best Conversion Practices When Moving Data to a New Accounting System

One of the biggest questions companies face when they move to a new accounting system is the amount of data to bring forward from the old one. The temptation is to keep as much information as possible but that policy has little merit while increasing risk and cost.

1. Data table definitions are likely very different from the old to the new system

This factor greatly increases both risk and cost. Whether you are talking about inventory purchase and sales history or historical customer and vendor transactions, moving legacy data may have a huge impact on the new system. A posted sales invoice, as an example, may impact up to fifteen to twenty unique tables, meaning that any reports or functions, such as inventory replenishment routines, may be working with incomplete or inconsistent data, if you try to bring legacy data forward.

2. General ledger data can often be brought forward, if the information is consolidated to an appropriate level

There are number of factors that influence the success of this action. The first is the consistency of the chart of accounts between the two systems. New account numbers or changes in account numbers can be accommodated, with a conversion table, if there is a “one to one” relationship or “many to one” relationship between the old and new account numbers. “One to many” relationships can only be accommodated if the company is willing to spend a lot of time analyzing the transactions in the account to determine how they should be split up. Account segmentation and cost dimensions also affect the ability to create consistent reporting using old and new data in the new system. Sometimes, it just makes sense to start with a balance sheet as of the conversion date if there are just too many differences. At other times, net changes by account by month will work well. If the systems are completely compatible, a company may choose to bring in several years of detailed data. If you choose the detail route, make sure there is time to post the data before you need it.

3. Imported data should be imported into posting journals, not directly into tables

Importing data directly into tables by-passes the business rules necessary for the system to work properly. Better systems have a variety of journals that data can be dropped in. Using the post function in these journals forces the data to pass the business rules in place. Directly importing data requires a perfect understanding of the data structure and manipulation of the data from the legacy system to it will match the new schema. High risk, for both cost and the time delays that may result if the process doesn’t work out perfectly. In many cases, the problem with data will not become obvious until the system has been live for several days or weeks, which requires either a huge reset to re-do the “go live” or massive effort to analyze and fix the errant information.

4. Customer, vendor, and inventory item tables as often full of old data

A major advantage of moving to a new system is shed inactive customer, vendor, and inventory item records that are no longer applicable. In some cases, only 20-30% of records should be brought forward. This is the change to clean things up and make the system easier to use after the conversion.

5. Make sure to run at least two practice data conversions with testing in the new system

The test data conversions do not have to include all data from the old system but they must include representative examples of everything to be brought forward, and not just a few samples. Remember, it is the exceptions that break processes, not the 99% that are all the same. There can’t be any hiccups in this process when the “go live” data conversion is carried out as there is often little time for re-doing it, if something doesn’t work. Data conversion routines, which often require data validation as transactions are imported and posted, can run for several days straight.

6. Pick a time of year when things are slower, not necessarily the year-end

It might seem obvious but picking a time of year to prepare for a system conversion, run the data conversion, and then work through reduced productivity while people learn the new system, is an important factor in reducing the stress on the organization and people. Make sure they have the time they need to work on the data preparation, testing, and training or hire more people to make that possible. Year-end is often the worst time to convert to a new system as the finance people, in particular, are going to very busy with quarter-end, year-end and auditors.

7. Be ruthless with data to be brought forward

One of our larger customers converting to Microsoft Dynamics NAV was adamant about needing two years of purchasing history for their purchasers. It turns out the purchasers never used the legacy data, wasting significant effort and incurring unnecessary costs. Every request to bring legacy data forward, other than the basic items, should be accompanied by a business case.

8. Keep the old system running as long as possible

Depending on the circumstances, the company may be able to keep the old system running with a few user licenses in case anyone needs to query the system. After a few months on the new system, it is unlikely that anyone will need to access the old one. Reliability of the old system isn’t so important. In some cases, a report writer may be able to combine information from both systems, creating a cost-effective and useful solution.