What Data You Should, and Should Not, Migrate From Your Old ERP System to the New

Back to Knowledge Bank
Posted by: briansittley Comments: 0 0 Post Date: October 23, 2018

Managing enterprise data has never been more difficult.  This becomes all too apparent during that critical stage of business management software turnover when it comes time to decide what data to migrate over from the old system to the new, and by implication, what data not to migrate.  We offer a few simple tips here today.
System implementers generally consider your company data to be of two types, often called “Master” (or static) and “Transactional.”  The former consists of the key organizational data elements – things like employee names; inventory part items and descriptions; vendors; customers; general ledger accounts and their numbers.  In other words, the kinds of data that are relatively fixed in nature, referred to frequently, and generally pretty static in terms of their consistency over time.
The other data, transactional records, consists of the everyday events (transaction) records that occur in business, like creating and invoice or adding or removing items from inventory due to production, sale or other effects upon an item.
Technically, a third category might be considered starting balances, or opening general ledger account balances as far as the new system is concerned.
Nowadays, it’s common to use spreadsheets or the tools provided by the vendor to assist in this process.  For example, customers moving off a legacy system into a Dynamics 365 (D/365 cloud-based) environment would use Microsoft’s “Data Management Framework” tool, first to extract data from a legacy system, then transform that data to a relevant framework for the new system, and then import the data into the D/365 application – thus: extract, transform, import.
Here’s what we and others suggest, based on having tried many approaches over many years with many clients, some more successful than others.
Step 1: Use the available tools to migrate all the Master data you can by extracting it, transforming it (usually using a tool or an Excel spreadsheet) into the appropriate new-system fields, then importing the data into the new system.  You’ll save yourself both money and frustration if you carefully review all the data during that transformation process to clear out any old, inactive or inaccurate records.  Clean up your data here and now, one time, so you start fresh and clean in the new system.
Step 2: Don’t even think about porting over (migrating) all your various and complex transactional data.  Your old system and new will handle those transactions in radically different ways, and the odds of migrating your data cost-effectively or efficiently are slim at best.  Somebody will eat an inordinate number of hours trying to migrate your transactional data (trust us).  It’s not worth it, as it’s a whole lot simpler to just leave the legacy system running after you cut over to the new system, so it’s available merely for inquiry purposes, if you really need to look up that transaction later.  You might be surprised at how seldom you’ll need to do this.
Step 3: Then finally key in your beginning G/L account balances into your new system for each G/L account.  It’s not that big a task, and the data entry practice will do your users good.
Approaching your migration along the simple lines we’ve defined here will give you the most bang for your buck, and keep your migration moving forward at a reasonable pace, while limiting the frustration that your employees and your partners would otherwise face by thinking you can simply transfer “everything” from the old system to the new.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Knowledge Bank