So, you have decided to adopt NetSuite as your ERP. Great! As with all ERP migration, you’re going to need to perform a data migration to move your old system’s data into NetSuite. It is essential that this migration be done correctly, or your data may suffer from what is essentially permanent damage. Yikes! We don’t want that!
Data Scope Strategy
As NetSuite partners, when we bring data migration scope up, many customers’ initial reaction is something along the lines of “well, let’s bring over everything” or maybe “the last 5 years should be plenty.” Taken in a purely logical point of view, this makes sense. Why would you want to lose data?
The problem is cost. Every single record adds to the cost of migration. There isn’t a big difference between 10 and 100 records, but there is between 100 and 1,000. It adds up fast. A very loose metric might be to consider that every migrated record is going to cost you somewhere between 10 and 50 cents to migrate. Some organizations could have more than a million combined records of varying types. Moving ALL of that gets pricey!
Do you need to know exactly what items customers bought or do you just need to know the dollar amount customers spent on orders? Do you need to migrate all your closed opportunities? Do you need to know what you bought from which vendor, when and for how much?
Maybe you do. Companies that are very product focused may need to report on historical product sales trends, so they need to know exactly who bought what when.
However, for many organizations, it’s not relevant – or rather, not relevant enough, to justify the cost.
For many, some transactional data, such as monthly accounting figures, are sufficient. You really have to decide whether you are going to actively report on that data or not.
Keep in mind that in many cases, your full legacy data can still be parked somewhere if a need ever arises to access it. In cases of NetSuite-to-NetSuite migrations in particular, it’s worth noting that NetSuite offers “Archived Instances”. These are read-only NetSuite instances with 1 or 2 user logins. Other legacy systems may offer options in the same vein. Worst case, keeping everything in CSV files somewhere may be a sufficient option.
Key Steps for a Successful Migration
For every record type you are migrating, you will want to follow these 7 steps:
- Map legacy system fields to NetSuite fields
- Export Data
- Massage/modify/convert legacy data to conform to expected NetSuite formats
- Perform trial import
- Adjust & repeat steps 1 to 5, as needed
- Fire for effect
- Verify and perform corrections, as needed
Some pick this time to perform a general data cleanup, including de-duplication and removal of inactive records. This is certainly a worthwhile effort, but keep in mind you’ll be adding additional time and effort to an already difficult process. Be sure to plan for the impact this is going to have on budget and timeline.
Keep points to keep in mind:
- ALWAYS set an External ID, a field specifically used to track the legacy primary key of the record from your legacy system, on your records. If you do not, then you will have no reliable way of matching imported data to your legacy data. This is vitally important to be able to do when you realize there are mapping errors.
- Map to Internal or External IDs when referencing other NetSuite records, unless it is very simple list data. The effort of running vlookups and/or search and replace to convert the values will be worth it.
- Verify your data thoroughly. If you are not a vlookup expert, stop what you’re doing and become one. Do not proceed with migration unless you can perfectly explain vlookup to a 5 year old, and then explain it again to a NASA rocket scientist.
Migrating A/R, A/P and Financials
I commonly see accounts where A/R and A/P transactions were migrated and then the full Balance Sheet was migrated on top, which includes A/R and A/P balances. Of course, that double booked A/R and A/P, so what do you do? Post a Journal to back out the value of the migrated A/R and A/P, right?
This is a very common mistake, but why is it wrong?
It’s specific to NetSuite. Journals allow you to book A/R and A/P without specifying an entity that owns that debt. The problem with that is that NetSuite will show any impact to A/R or A/P on its aging reports. Any amount posted without an owning entity will show up in the “No Customer” section. The only way to stop something from aging is to close it. The only way to close something is to Apply Payment and it is only possible to apply payment to debits and credits that are tagged to a specific entity.
In other words, if you post A/R or A/P without a name, you will never be able to close off that amount and prevent it from appearing on NetSuite’s aging report. Keep in mind that once the period those bad journals reside in are closed, you can’t set a name on it anymore. Without a name, you will literally never be able to fix your aging report.
Some will then edit aging reports to hide anything going to “No Customer”. That will mask future possible postings to No Customer. You WANT to see those because that should be a signal for you to go and correct these entries. A/R booked to “No Customer” is A/R you aren’t likely to know how to collect.
Instead, follow this recipe:
- Import your open A/R and open A/P into NetSuite as transactions. These should, minimally, have the proper date, total amount and the proper customer/vendor they belong to.
- Pull the Trial Balance from NetSuite for the month(s) you are planning on importing opening balances from the legacy system
- Pull the legacy system opening balance(s) you mean to import. Get that in Excel.
- Subtract from the legacy balance(s) the NetSuite Trial Balance results.
- Now import the modified opening balance(s)
This is the proper way of migrating financial data in NetSuite if you want to avoid long-term problems and junk appearing on your aging reports forever.
Hopefully, these tips are helpful as you move forward with your data migration. Of course, please contact us if we can assist you with your data migration.