One question that inevitably arises when clients embark on the move from an older, legacy ERP system to one of today’s more modern ERP systems involves the task of importing historical data from the old system to the new.
It turns out that the detailed answer is typically different for every client we encounter. However, a couple general principles usually hold true. We’ll cover the basics today.
When it comes to most data conversions, usually the first decision is the choice between importing only “static” (or “master”) data, versus importing “transactional” data. Static data includes standard things like customer names and addresses, A/P vendor info and inventory item numbers and descriptions. It’s generally information about persons, entities and objects. It usually remains fairly constant over time. These data are typically stored in logical, two-dimensional tables, and are usually relatively easy for your technology partner to ‘port’ from an old database structure into a new one. It’s typically your firm’s “core” data, and fortunately, it’s relatively inexpensive in the grand scheme of things – and usually very necessary – to bring over.
This is especially true (and hence, usually less costly) if your solution provider knows the data structures of both your old system and your new.
Transactional data is usually more problematical – and thus more expensive to consider porting. Clients typically have healthy debates about ‘the right’ path to follow. Bringing in transactional data adds a layer of complexity in all cases. Usually, to port transactional data requires a pretty deep understanding of your legacy system and its data constructs and locations. In addition, it’s usually necessary to determine which transactional data should be ported. The more –and the more complex — the data, the more complicated and thus costly the migration. The new ERP system will not have the same data structure as the old one. Those charged with porting the data may argue for bringing less data across, given that they’re the ones who actually have to do it. Meanwhile, actual users of the data may argue strongly for its necessity to exist in the new system.
Each client needs to work out the particulars with their solution provider. The resolution is ultimately decided by the organization’s needs, but it’s not always apparent at the outset.
There is one other method gaining popularity today, especially for larger companies with significant data upgrade needs, and we’ll introduce that in our next post. Stay tuned…
We often counsel clients with a fairly straightforward, inexpensive suggestion: What if you ported the master (static) data, along with all the necessary balance-forward general ledger financial data (beginning balances for each G/L account), but then skipped the transactional data? Instead, would you consider keeping the old system up and running for awhile, so users could, if really necessary, “peek back” in time to the old system for the data they need on a case-by-case basis. Frankly, users may find that the old transactional data to which they clung so tightly might turn out to be less mission-critical than they first surmised.
At the least, this may support delaying a final decision on porting data until an operational conclusion can be drawn a few weeks in – thus potentially, at least, saving the firm some costs that may have turned out to be unnecessary after all.