Ensure a seamless transition with our comprehensive NetSuite data migration strategy checklist. Minimize risks, maintain data quality, and drive business success.
Data migration is the part of an ERP implementation that gets the least attention in planning and causes the most delay in delivery. It sounds mechanical, it is described in a single line on most project plans, and it routinely consumes more effort than the system configuration it supports.
The reason is that migration is not a technical exercise. Extracting and loading data is the easy part. Deciding what the old data actually meant, what should happen to records that do not fit the new model, and who has the authority to make those calls is the work.
This article is the checklist we use, in the order the decisions need making, with the traps that catch most projects.
Start with scope, because every downstream decision follows from it and because the first answer is usually wrong.
Master data is not optional. Customers, suppliers, items, employees, the chart of accounts. Without these nothing else can be loaded.
Open transactions are also not optional. Outstanding receivables and payables, open orders, unfulfilled commitments, current inventory positions.
Opening balances have to come across so the ledger starts from a correct position.
Historical transactions are where the real decision lies, and the honest question is what you would actually do with them. Most businesses ask for several years of history and then never query it in the new system, because the reporting they need is either current or was extracted before cutover.
History is the single largest driver of migration effort and it deserves a proper challenge rather than a default answer.
Ask what specific question needs historical data to answer, and how often it is asked. Vague answers about wanting the history available usually indicate a comfort requirement rather than a business one.
Consider whether the requirement is satisfied by keeping the legacy system available in read only form for a defined period, which is frequently cheaper, faster and lower risk than migrating.
Consider whether summarised history would do. Monthly balances by account and dimension satisfy most reporting requirements at a fraction of the effort of transaction level migration.
And be aware that historical transactions carry the old dimensional structure, so migrating them does not necessarily give you comparable reporting anyway, which is a point most businesses have not considered.
Separate from what is useful is what you are required to keep, and the two are not the same.
Australian tax law requires records supporting your returns to be kept for a defined period, and employment records under the Fair Work Act have their own retention requirement.
Those obligations can be satisfied by an archive rather than by a live system, which is an important distinction because it decouples compliance from migration scope.
Decide explicitly where the archive lives, who can access it, and how long it is retained, and write that down. Where this is not decided, businesses default to migrating everything, which is the expensive answer to a question that had a cheaper one.
Confirm the current requirements with your accountant rather than relying on what was true previously, since retention rules change.
Most migration plans are built on an assumption about data quality that turns out to be optimistic, which is why they slip.
Profile the actual data early. How many customer records, how many are duplicates, how many are inactive, how many have incomplete addresses or missing tax details.
Do the same for items, suppliers and employees. The findings determine the timeline more than the transaction volume does.
Look for the structural problems too. Fields used for something other than their intended purpose, free text where a code should be, information encoded in naming conventions that will not survive the move.
Doing this before the plan is written turns a guess into an estimate, and it is a few days of work that routinely saves weeks.
The most consequential planning assumption to get right is who does the cleansing, because the wrong answer here derails projects.
Deciding whether two customer records are the same customer requires knowing the business. So does deciding which of three variants of a supplier name is correct, or whether an item that has not sold in four years should still exist.
Your implementation partner cannot make these decisions and should not be asked to. They can identify the candidates, produce the working lists and load the results, and the judgement is yours.
Which means somebody in the business needs allocated time for it, and that time competes with their normal work.
Projects that assume this capacity will be found rather than protected are the ones where migration becomes the critical path.
The temptation is to load everything and tidy it up later, and it is almost always the wrong call.
Cleansing in the legacy system, or in an intermediate working file, is considerably easier than cleansing in the new system, where records are already linked to transactions.
Merging duplicates after migration is difficult and sometimes impossible without losing transaction history, which is exactly the history you migrated at some cost.
Bad data also undermines confidence at precisely the point when confidence matters most. A user who finds three versions of the same customer in the first week concludes that the new system is worse than the old one.
And the tidy up later plan reliably becomes never, because after go live everybody is busy with more urgent things.
Field mapping is where most of the detailed work sits and it repays being methodical.
For every field in the new system, establish where the value comes from, what the default is where no source exists, and what transformation is required.
Pay attention to fields that have no equivalent in the old system, because those need either a default, a derivation rule or a manual decision per record.
Pay equal attention to fields in the old system with no destination, since each one is either genuinely obsolete or a requirement nobody has surfaced yet.
And handle codes and lists carefully. Where the old system used free text and the new one uses a defined list, somebody has to map every distinct value, and the count of distinct values is usually higher than anybody expects.
Migration is where the dimensional structure becomes concrete, and it is worth understanding the implications before loading anything.
Subsidiary, department, class and location determine the entire universe of questions the system can answer without a special exercise, and they need to be present on migrated transactions to be useful for historical reporting.
Where the old system did not carry an equivalent dimension, migrated history cannot have it, which means comparative reporting across the cutover will be limited regardless of how much history you bring.
Where the old system carried a different structure, somebody has to decide the mapping, and that decision affects every historical report.
This is one of the strongest arguments for migrating less history and keeping an archive, since the comparability people imagined is frequently not achievable anyway.
Records depend on other records, so the order of loading is not arbitrary.
The chart of accounts and the dimensional lists come first, since everything references them.
Then master data, with the dependencies within it respected. Items may reference categories and units of measure. Customers may reference terms, price levels and sales representatives.
Then opening balances, then open transactions, then history if any.
Build the sequence explicitly and test it in full at least once before cutover, because discovering a dependency problem during the cutover window is an expensive way to learn it.
A single trial migration proves the mechanism works. It does not prove the data is right.
The first trial usually surfaces mapping errors and dependency problems, and the value is in the error list rather than in the loaded data.
The second trial, after fixing those, surfaces the data quality issues that the first run's errors were masking.
A third, close to cutover with recent data, confirms that the process is repeatable within the window available and gives you a realistic duration.
Each cycle should be timed, because the cutover plan depends on knowing how long the load actually takes rather than how long somebody thinks it should.
Data that loaded without errors is not the same as data that is correct, and this distinction catches out more projects than any technical failure.
Reconcile record counts by type, and investigate every difference rather than accepting an approximate match.
Reconcile financial totals to the legacy trial balance, at account level and by dimension where applicable. This is the reconciliation that matters most and the one auditors will ask about.
Reconcile the sub ledgers independently. Total receivables in the new system should match the legacy ageing, customer by customer rather than in aggregate.
And have the business verify a sample by inspection, since a customer record can reconcile numerically and still be wrong in ways only somebody who knows that customer will notice.
Migration needs a defined acceptance point rather than a gradual drift into go live.
Agree in advance what constitutes a pass. Which reconciliations must balance exactly, which may carry a documented difference, and who accepts each.
Get sign off from the people who own the data rather than from the project team, since the finance lead accepting the trial balance is a meaningfully different thing from a project manager marking a task complete.
Document any known differences and the reason, because somebody will ask in six months and the answer being written down is worth a great deal.
And decide in advance what would cause you to defer cutover, so that the decision is made against a standard rather than under pressure.
The final migration happens in a compressed window and it rewards detailed planning.
Write the sequence hour by hour, with who does what, what must complete before the next step begins, and who confirms each one.
Freeze the legacy system at a defined time and communicate it widely, because a transaction entered after the extract creates a discrepancy nobody finds for weeks.
Build in a verification step after the load and before opening the system to users, with enough time to actually check rather than to glance.
And know your rollback position, including the point after which rollback is no longer practical, because deciding that at three in the morning is how bad calls get made.
The legacy system needs a defined end state rather than being left running indefinitely.
Read only access for a defined period is the usual answer, and it is what makes migrating less history a comfortable decision.
Set the date on which it will be decommissioned, and communicate it, because a legacy system left available becomes a legacy system people keep transacting in.
Take a final archive before decommissioning, in a format that is readable without the application, and store it somewhere the business will still be able to find it in seven years.
And confirm what licensing or hosting costs continue while it remains available, since this is a cost people forget to include in the migration decision.
Some failures recur often enough to be worth naming directly.
Underestimating cleansing, which is the most common and the most consequential, because it lands on people who have no spare capacity.
Migrating history nobody uses, which consumes effort that should have gone into testing or training.
Reconciling at aggregate level only, which hides individual errors that surface later as customer disputes.
Loading data that was extracted weeks earlier and has since moved on.
And treating a successful load as a completed migration, when the verification is the part that actually matters.
Data migration goes well when the scope is challenged properly, the cleansing is resourced as business work, and the reconciliation is treated as the acceptance test rather than as a formality.
The single highest value thing you can do early is profile your actual data, because it converts an assumption into an estimate and it usually changes the plan.
The second is to challenge the history requirement honestly, since that decision drives more effort than any other.
Our pieces on the implementation journey and tackling legacy migration challenges cover the surrounding project, and partnering and planning covers the decisions that sit above it.
If you would like help scoping a migration properly, get in touch.
