When choosing a new ERP or accounting software system, consider how you will migrate the data in your existing system into the new system. You don't want to have to re-enter all those products and customers, and you definitely don't want to lose things like sales history. You'll also usually want a way to transfer opening balances at date of go-live - unpaid payables, uncollected receivables, bank and general ledger balances to name a few.
Virtually every vendor will tell that you data migration is no problem. And usually that's true - but frequently only for the vendor. For you, it can be a big problem. Here are 5 tips for planning data migration:
1. Evaluate and understand your existing data.
Think about all the types of data you currently have, that you'd need or want in the new system. Consider reports and on-screen inquiries, and both current and historical data. Review the quality of your existing data: do you have a lot of duplicated customer records? Are you satisfied with your existing product codes? How about your chart of accounts? If you want to change anything, now's the time to do so.
2. Determine what data needs to be electronically migrated.
At a minimum, think about customers, vendors, products, bills of materials, sales history, financial history, and of course current transactions - these include unpaid / opening balances and open sales and purchase orders. What about quotes? Leads?
Think also about some of the subsidiary data - for example, an inventory management system may also track things like serial numbers, or lots and their original and remaining quantities if you're a food distributor. You don't want to have to manually re-build that data, do you?
In each case, look at quality and quantity. If you have very poor quality data, you may want to manually clean it before electronically transferring it. If a particular file is small (example - you only have 25 vendors), then it may make more sense to simply manually key these into the new system instead.
3. Understand when data needs to be migrated.
Timing is important. Customers and products for example, can be migrated any time ahead of go-live, with any new additions manually updated (you need a good process for tracking this). Alternatively, this information could be migrated at go-live (assuming you do a test migration ahead of time to validate). Current / open transactions and balances usually need to be migrated at point of go-live, and so can be the bottleneck (there are ways around this). But, for historical data such as sales history, timing is much more flexible - you could import sales history any time after you're already live on your new system.
4. Clean up your data.
Plan on taking responsibility for cleaning up bad or poor data, before turning the data over to the vendor (or the vendor's import utility). A common example when migrating from certain older or lower-end accounting systems is with customer addresses - where the city and zip / postal code are not stored in a consistent place - but the new system maintains separate fields for these and uses them for reporting, sales taxes, etc. In such a case, extracting the data into a spreadsheet, and moving those elements to their own columns, is a great idea. Usually the vendor will be able to supply you with a template that can then be imported into the new system.
5. Clearly define who is responsible for which activities.
Some vendors will give you a fixed cost for data migration - but please read the "fine print" on what that excludes. Similarly, some will tell you that you can use their import utility to import your old data without intervention from them. This may be technically true, but you likely do not have the depth of knowledge of their system to understand the implications of the choices you make using the import utility - sadly by the time you find out the consequences of a poor choice, it's too late.
Others will charge you an hourly rate for data - in this case be very careful to get details of what they propose doing, an agreed upon maximum number of hours, and a process to limit the costs and review progress in advance of any scope creep.
It's usually best to keep the vendor responsible for providing guidance on data types and formats, and for the actual import process, while taking ownership yourself of the quality of the data. Either dump your data into a spreadsheet yourself, or get the vendor's assistance in so doing, and use the spreadsheets to review and clean the data.
