Last updated: August 22, 2026
A clean ERP go-live comes from moving less data, not more, taking open transactions and current master records across while history stays behind in the old system as read-only, with every load reconciled to a number finance already trusts. That is the whole method. Most projects invert it, move everything they can reach, and then spend the first month after go-live paying people to argue about which system is right.
Two numbers from the same company, pulled the same week.
About 113,000 finished units shipped in a month. Roughly 70,000 units entering serialized inventory that same month. Both figures came out of systems the business had run for years, both were reported to somebody every month, and nobody had put them next to each other on one page. So nobody knew there was a 43,000-unit hole in the middle.
We found that during discovery on a regulated manufacturer, before a single record moved. Lucky timing. The bad version of that story is the same variance surfacing in week two of hypercare, found by a controller who now cannot close the month, cannot explain the inventory number, and has forty people standing at her desk asking her which system to believe.
Nobody schedules that meeting. It just shows up.
Worth saying who is talking. I run an ERP and integrated-systems consulting group, so companies with a fifteen-year-old system and a migration nobody wants to own are exactly who ends up on my calendar. You are also reading this on a staffing firm’s site, and KORE1 places the people who own the data after consultants like me hand over the keys. Neither of us is neutral. Weigh it accordingly.
If you are still choosing a platform, back up and read how to choose an ERP for a mid-market business first. This piece assumes the decision is made, the contract is signed, and somebody just asked you what happens to twelve years of transaction history. KORE1’s ERP recruiters field that call at roughly the same point in a project, usually phrased as “we need someone who has done this before, starting Monday.”
Migration Is a Subtraction Problem
Here is the reframe that saves the most money, and almost nobody starts here.
You are not moving your data. You are deciding what to abandon.
Every record you carry across has to be extracted, mapped to a field that may not exist in the new system, cleaned, loaded, tested, reconciled, and then defended when somebody says it looks wrong. Six activities per data object. Run that math. A team migrating thirty objects is not doing three times the work of a team migrating ten. It is doing considerably more, because objects have relationships and every relationship is one more thing somebody has to prove is still true after the load.
So the first real deliverable is a list of what is not coming. Written down. Signed by someone who can say no.
The usual objection arrives immediately. What if we need it? Sure, you might. Keep the old system running read-only for two years, or export history to a warehouse or a flat archive finance can query. That costs a fraction of migrating it and carries none of the risk of poisoning your new master data with records that were already wrong in 2019.
MIT Sloan Management Review published research by Thomas Redman in 2017 finding that 47 percent of newly created data records contain at least one critical error, and that only 3 percent of the data quality scores measured were acceptable under the loosest standard the researchers could apply. Those are records being created today, in a running business, by people who are paying attention. Now picture the ones created in 2014 by somebody who left in 2016.
You are not preserving history. You are laundering it.
The Two Line Items Almost Every Fixed-Fee Quote Excludes
Read the exclusions page of any ERP proposal you have been handed. I write these, so I will tell you exactly what to look for.
Two items appear on nearly every one. Remediation of pre-existing data quality issues found during discovery. And historical data migration. Both excluded, both scoped separately, both discovered after you have signed a fixed fee for everything else. Not sometimes. Every proposal.
That is not a trick. It is honest, and I put those exclusions in my own proposals for a defensible reason. I cannot price the cleanup of a data set I have not seen, and any firm handing you a fixed number for it before discovery is either padding heavily or planning a difficult conversation in month three. But honest and free are different things, and the effect on your budget is identical either way. You still pay.
Which produces the rule I would want a CFO to take from this whole piece. A materially cheaper ERP proposal is usually cheaper by exclusion, not by efficiency. Put the two quotes side by side, ignore the totals, and compare only what each one refuses to do. The gap is the price.
| Data work | Usually in the fixed fee | Usually your problem |
|---|---|---|
| Field mapping for agreed objects | Yes | No |
| Deduplicating your customer and vendor master | Rarely | Yes, and it takes longer than you think |
| Deciding the correct value when two systems disagree | Never | Yes. Only you can make that call |
| Loading and validating agreed objects | Yes | No |
| Historical transactions beyond the agreed window | No | Yes, priced separately |
| Remediating configuration or data defects found in discovery | No | Yes, with an impact assessment attached |
The second column is the one people read. The third column is the one that shows up on your P&L. There is more on where the money actually goes in the most expensive implementation mistakes, which covers the quote-reading habit in detail.
Tier the Data Before Anybody Writes a Mapping Document
Tiering is old advice and it works, which is why it survived. The version that works is stricter than the version most teams run.
Three tiers. Not five. Five tiers means nobody decided anything.
- Tier one, transact on day one. Active customers and vendors, the item master you actually sell, open sales orders, open purchase orders, open AR and AP, on-hand inventory with correct costing, the chart of accounts, and opening balances. If the business cannot take an order Monday morning without it, it is tier one. Nothing else is.
- Tier two is reference data. Closed transactions inside a defined window. Current fiscal year plus one prior year for comparatives is the usual answer, then whatever your auditors want on top of it, and that is a conversation to have in October rather than the week before cutover when the same answer somehow costs three times as much. Ask them. Do not guess on their behalf and do not let a project manager guess either.
- Everything else is tier three, and tier three does not migrate. It gets archived, and the archive gets a documented retrieval path with a name attached to it. Somebody has to be able to answer a subpoena or a customer question in 2029 without reopening a decommissioned server.
That is the whole taxonomy. Watch what happens to an estimate when a business genuinely commits to it. Migration hours drop by half or better on most mid-market projects I have run, and testing hours drop with them, because you are only proving the correctness of things that matter this week.
One caution on tier one, because it is where the surprises live. On-hand inventory with correct costing is four separate problems wearing one label. Quantity, location, valuation method, and the layers underneath the valuation. Teams routinely scope it as a single object and find the fourth problem in the last week. Usually the layers.
Reconcile to a Number Finance Already Signed
This is the discipline that separates a clean go-live from a long one, and it is not complicated. It is arithmetic.
Before any load, pick the control totals you will reconcile against. Total AR by aging bucket. Total AP. Inventory value by category. Trial balance by account. Take those from a period finance has already closed and signed, not from a live query that moves while you are looking at it. Agree them in the same meeting where you agree the tiers, put them on one page, and get finance to say out loud that these are the numbers the migration will be judged against, because a control total invented after a load has already failed is not a control total. It is an argument.
Then load into a sandbox and compare. Not sample. Compare. If the AR total is off by $1,847, that is not a rounding issue. It is a rule you have not found yet, and it will still be there in production.
Three full rehearsal loads is the number I hold teams to. The first fails badly, and it is supposed to. The second fails in ways you can explain. The third runs clean and, critically, runs inside the cutover window on the hardware you will use for real. A load that reconciles perfectly but takes nineteen hours is not a passing test if your window is twelve.
Sign-off is per business function, and it belongs to the function, not to IT. Finance signs balances. Procurement signs the vendor master and open POs. Warehouse signs quantities and locations. Sales signs the customer master and open orders. Four names, four signatures. If one person signs all four, nobody signed anything.
The Government Accountability Office reported in June 2025 that across 24 critical Defense Department IT business programs, 12 had reported cost increases and 7 had reported schedule delays, with one financial management system running four years past its original deployment date. Unlimited budget, mandatory compliance, decades of process documentation, still four years late. Data conversion from legacy systems turns up in GAO findings on these programs again and again, going back twenty years.
Your project is smaller. Your data is not necessarily better.
A Migration Script Is Code, So Treat It Like Code
Most mid-market migrations run on a pile of spreadsheets and one person’s transformation scripts. Works fine right up until somebody needs to know why a value changed.
Borrow the discipline from regulated work, where this is not optional. Our change control process is written down because clients audit it, and four rules from it apply to any migration on earth. The same document governs AI-assisted code generation, which I covered separately in AI-augmented development rules.
- Every change gets recorded before the work starts, with a reason. Not after, when the reason has become “I think Dave asked for it.”
- Changes get reviewed before merge by somebody other than the person who wrote them.
- Changes are never bundled to dodge assessment. Three small transformations shipped together get assessed individually and then assessed again as a combination, because the combination is where the interesting failures live.
- Nothing is edited directly in the production environment. Ever. Not on cutover night, not to fix one record, not because it is faster.
That last one gets broken constantly. Always at 2am, always by the most senior person in the room. It always seems reasonable.
Then there is AI, which is in every one of these projects now whether it is in the plan or not. Somebody on your team is generating transformation logic with a model. I do it too, and my view of the thing has not moved in two years. AI is a high speed idiot, which is a phrase I have worn out on this site, and I keep using it because nothing better has turned up. It will transform ten thousand records without complaint and without wondering once whether the mapping was right.
So govern it the way you would govern a capable intern. Point it at simple work. Generate against a written specification, never a prose request. A named human stays author of record for anything that ships. Review before merge is mandatory, and it gets documented. And the tests proving the AI-assisted code did the right thing get written by a person, because a model grading its own homework is not a control and no auditor on earth is going to accept it as one. We put that in writing as policy. Almost nobody else in the ERP space has published theirs, which tells you where the industry is on this.
Cutover Is a Rehearsal, Then a Performance
Cutover is a schedule with named owners and a clock, produced in advance, in writing, down to the hour. Actual hours. Not phases.
The parts people forget are rarely technical. When does the old system go read-only, and who physically turns that off? What happens to orders placed during the blackout window, and has anybody told sales? Who holds stop authority, meaning the one person who can say we are rolling back, and does that person have a phone number that works at 3am? Every one of those has an obvious answer in a planning meeting and no answer at all at eleven o’clock on a Saturday night, which is exactly when somebody needs it and instead makes the call alone. Write the answers down.
Set the rollback trigger before you are tired. “We roll back if the trial balance does not tie by 6am Sunday” is a decision made by rested people. At 6am Sunday, with a load 90 percent complete, nobody rolls back voluntarily. Human nature, and no amount of seniority fixes it.
Then hypercare. Budget three weeks of it, staffed, before anybody returns to a normal calendar. On a regulated integration I priced recently, release and hypercare was a four-week phase and three of those weeks were hypercare. Not because the software was fragile. Because the first three weeks are when real users touch real data and find every assumption the project made about how they work.
More on the governance side of this, including who should hold stop authority and whether you need a parallel run, is in the QuickBooks to NetSuite migration guide.
What This Costs and How Long It Takes
Real numbers, from real proposals, so you can sanity check whatever landed in your inbox.
Blended delivery rates at a specialist firm run around $215 an hour across roles. One number covering architects, developers, and functional consultants, and I prefer it to a rate card because a rate card invites you to buy cheaper hours and then wonder why the estimate grew. Discovery with a risk assessment and a validation plan came in at 182 hours and $44,110 fixed on a recent regulated engagement. That is the phase people try to skip. It is also the phase that prices everything after it, which is the actual argument for doing it. Skip it, pay it twice.
| Phase | Typical duration | What the data work looks like here |
|---|---|---|
| Discovery and risk assessment | 4 to 5 weeks | Profile the source data, agree the tiers, find the variances, price the cleanup |
| Design and build | 10 to 12 weeks | Mapping documents, transformation logic, first rehearsal load |
| Test and validate | 8 to 10 weeks | Rehearsal loads two and three, reconciliation, function-by-function sign-off |
| Release and hypercare | 4 weeks, three of them hypercare | Production load, blackout window, daily reconciliation, defect triage |
Call it 22 to 26 weeks for a mid-market implementation where the data is in reasonable shape. Two things drive the range and neither is technical. How much rework the specifications need after the first review, and how long your own team takes to approve documents. Delay caused by waiting earns you schedule relief. Delay caused by rework earns you an invoice. Different causes, different consequences. That distinction is worth writing into the statement of work before you sign, and I would say so even sitting on your side of the table.
The McKinsey and University of Oxford study of more than 5,400 IT projects found large ones run 45 percent over budget, 7 percent over schedule, and deliver 56 percent less value than predicted. The third number is the one to sit with. Budget and schedule miss by a lot. Value misses by more. A company can absorb a cost overrun. A system nobody trusts is a different category of problem, and trust dies at the data layer first.
Gartner is blunter about it. Their published guidance to IT leaders holds that by 2027, more than 70 percent of recently implemented ERP initiatives will fall short of their original business case, and that as many as a quarter of those will fail outright. That is their number, not mine. My read on it is that almost none of those projects picked bad software. Most picked perfectly good software and then fed it whatever came out of the old system, which is a different failure with a different fix and a far smaller price tag if somebody catches it during discovery. If you want current rate benchmarks by platform before you negotiate, we published ERP consultant hourly rates for 2026 separately.
High-Quality Data Means You Stop Throwing Bodies at It
Here is the part that makes all of the above worth the argument, and it has nothing to do with go-live day.
Clean data is what lets a company grow without adding headcount every time volume climbs. Sounds like a slogan. It is not. Every reconciliation somebody does by hand, every report exported and fixed in a spreadsheet before anyone will look at it, every “let me just check that number” before a decision, all of it is a person spending part of their week compensating for a system nobody trusts. Those hours are real and they are on your payroll right now. Go count them.
We run our own ERP internally, and high quality data is precisely what lets us operate without throwing bodies at the processes. Same goes for the automation and AI everybody is asking about at the moment. An agent pointed at your order data is only as good as the order data. Garbage in, garbage out, except now it is confidently wrong at machine speed and somebody still has to catch it.
The team at justingredients.com had grown through $150 million in sales on systems that had stopped talking to each other. We rebuilt the stack in about seven months, and it now supports a business north of $250 million with real visibility across ecommerce and wholesale. The migration was the unglamorous part. It was also the part that made everything after it possible, because nobody had to ask whether the number was right.
Which brings this back to people. A migration needs specialists for a defined window, then it needs somebody permanent who owns the data model afterward. Two different hires, and companies routinely try to make them one. KORE1 staffs the first as ERP data migration specialists on contract, and keeps a separate desk for go-live and hypercare support, which is the phase everybody under-resources. Their searches close in an average of 17 days and 92 percent of the people they place are still in the role a year later. The second number is the one I would care about. A data model is only as good as the person who still understands it in eighteen months.
What Finance Asks Me Two Weeks Before Cutover
How much of our transaction history should we actually bring over?
Current fiscal year plus one prior year covers comparative reporting for most mid-market companies. Ask your auditors what they need in writing, archive the rest with a documented retrieval path, and keep the legacy system read-only for a couple of years if anyone is nervous.
Can we just clean the data after we go live?
You can, and it costs several times more. Cleaning in the legacy system is a spreadsheet exercise. Cleaning after go-live means correcting records that are already generating transactions, journal entries, and downstream documents, so every fix drags a tail behind it.
Our implementation partner says data cleanup is our responsibility. Is that normal?
Completely normal, and honest of them to say it early. No outside firm can decide which of two conflicting customer addresses is correct or which duplicate vendor is the real one. What they owe you is the profiling that finds the problems and an estimate for helping you fix them.
Three rehearsal loads sounds excessive. Is one really not enough?
One load tells you the script runs. That is all it proves. It says nothing about whether the result is correct or whether it fits the cutover window, and loads two and three are where timing, sequencing, and the ugly edge cases surface, which are the ones that ruin a weekend.
How do you spot a migration that is quietly going wrong?
Nobody can name the person who signs off on each data object. No name, no owner. When the answer is “the project team,” a data set has nobody who will defend it once the numbers get questioned in month two, and defending them is most of the job.
Should we hire for this or use the implementation partner’s people?
Both, for different windows. Migration specialists are a fixed-duration need and contract is the honest structure for that. The person who owns your data model afterward should be permanent, hired early enough to sit through the build, and should not be borrowed from the partner.
Pull One Report From Both Systems
Do this before your next steering committee. Pick your total AR balance as of last month end. Pull it from your ERP. Then pull the same number from whatever spreadsheet, report, or side system finance actually uses to answer that question. Two numbers, one question.
If they match, your migration is a smaller project than you have been told. Good. Spend the savings on testing.
If they do not match, you have found the shape of the work, and it is not a software problem. It is a decision nobody has made about which number is true. That decision does not get easier after go-live. It gets more expensive, because by then both numbers have children.
Run the comparison and hit me up on LinkedIn with what comes back. If the gap is architectural, that is my end of the work. If what you need is a person who has moved this kind of data before and can start in weeks rather than quarters, that is KORE1’s, and their business systems consolidation desk covers the messier multi-system version of this problem. Talk to the KORE1 team when the missing piece is a seat rather than a strategy.
