Every ERP migration plan I have reviewed treats data migration as a task on a timeline — extract, cleanse, load, validate, cutover — wedged between configuration and go-live. That sequencing is not wrong, but it hides where the real risk sits. Across more than 50 NetSuite implementations, the projects that struggled hardest were almost never behind schedule on configuration. They were behind on knowing what their own data actually meant.

Migration is a data strategy problem wearing a project-plan disguise

Data migration gets treated as a technical exercise: map the old fields to the new fields, write the transformation scripts, run a few test loads, ship it. That approach works fine for data that is already clean and well understood. It fails quietly for everything else, and in a company that has run its legacy system for a decade or more, "everything else" is usually most of the item master, a meaningful share of the customer file, and every custom field someone added for a one-time reason that nobody remembers.

The companies that get through a migration cleanly are the ones that treat it as a data strategy decision before it ever becomes an extraction job: which records are the source of truth, which legacy fields still mean anything today, and which processes need to change because the old data structure was covering for a process gap rather than reflecting one.

Where migrations actually break

The failure points are consistent whether the company is in manufacturing, distribution, or software:

  • Item and customer master duplication. Years of manual entry produce the same customer or item under three slightly different names, and no one owns the reconciliation until migration forces the question.
  • Historical transaction depth. Deciding how many years of open and closed transactions to bring over is a business decision, not a technical default, and getting it wrong either buries the new system in irrelevant history or strands reporting continuity.
  • Custom fields with no living owner. Every legacy ERP accumulates fields that mattered to a process that no longer exists. Migrating them by default just moves the clutter into the new system.
  • Integration dependencies nobody mapped. A field that looks unused inside the ERP may still be feeding a report, an EDI mapping, or a third-party integration that never came up during scoping.

None of these show up in a demo. They show up during user acceptance testing, or worse, a few weeks after go-live, when someone notices a customer's credit terms did not carry over the way they were supposed to.

Cutover is not the finish line

A clean data migration is judged the day after go-live, not the day of. The test that matters is whether the finance team can close the first month-end without a list of exceptions to chase down, and whether operations can run a normal day without falling back to the old system to double-check something. That bar is achievable, but only if the reconciliation and validation work happens well before cutover weekend, with enough time built in to fix what validation finds rather than just document it for later.

Ownership determines the outcome

The pattern I see most consistently is not a tooling problem. It is an accountability problem. Data migration gets split across a data team, a functional team, and an IT team, each responsible for a slice, with no one person who understands both the business meaning of the data and the technical mechanics of the load. That split is exactly where duplicate customers, orphaned transactions, and silent field mismatches survive testing.

That is why I stay personally involved in the data strategy and migration decisions on every engagement rather than handing that work to a project team after scoping. Across the NetSuite implementations I have led — 50-plus projects, a 98% client retention rate, and an average 3x ROI for clients — the migrations that held up were the ones where a single senior person made the judgment calls on what to bring over, what to leave behind, and what to fix before it ever touched the new system.

Data strategy is not a phase of an ERP migration. It is the decision that determines whether the rest of the project holds up once the consultants leave and the business has to run on what got migrated. Treat it as a checklist item and you will find out how wrong that was at your first quarter-close. Treat it as the central decision it actually is, and cutover becomes the anticlimax it should be.