You can get two numbers for an ERP migration in about a week. The licence delta — what the new suite costs per year against what you pay now. And the implementation fee — what a partner will charge to stand it up. Both are easy to produce, easy to compare, and easy to put in a board deck.
They are also the two numbers that vary least between reasonable options, which makes them close to useless for deciding anything. The variance that actually determines whether leaving was worth it sits in five line items nobody quotes, because four of them are work on your side of the boundary and the fifth has no invoice at all.
Naming those five is what turns an ERP migration from a leap of faith into a decision you can actually price.
A licence delta is a comparison of two published price lists. An implementation fee is a vendor's estimate of the work inside their own scope. Neither is wrong. Both describe the part of the project the vendor controls, and that part is not where migrations go over.
The pattern is old and well documented. McKinsey's study with the University of Oxford of more than 5,400 IT projects found that large IT projects ran, on average, 45 percent over budget and 7 percent over schedule while delivering 56 percent less value than predicted. That was 2012, and the shape of it has not changed, because the cause has not: the estimate covers the software, and the overrun lives in everything the software has to connect to.
So the useful exercise is not getting a tighter quote. It is counting the things the quote does not cover before you sign it.
Moving records between systems is a solved engineering problem. Deciding what the records mean is not, and that is the work.
A suite you have run for ten years contains three generations of convention. Customer records that duplicate because two divisions onboarded the same account and a human always knew which one to use. A chart of accounts that drifted through two controllers and a restructure. Item masters where part numbering changed twice and the old scheme still appears in open orders. Open transactions in states the new system has no equivalent for — a partially received purchase order against a vendor you no longer buy from, a credit memo under a tax treatment since superseded.
None of that is a data problem in the old system, because the old system does not care and the people using it have absorbed the exceptions. It becomes a problem the moment a machine has to map it. Every ambiguity has to be resolved by somebody with authority to decide, and there are usually thousands of them.
This is routinely the largest single line in an ERP migration, and it is the one most often missing from the vendor's number — not because anyone is hiding it, but because it is work on your data that has to happen before their scope starts. The sequencing discipline that prevents silent loss on a CRM migration is the same discipline at suite scale, with an order of magnitude more objects in play.
Every integration is a contract between two systems. Replace one side and every contract is void at the same moment.
The count is always higher than IT thinks, because IT knows about the integrations IT built. The business built the rest. The scheduled export that feeds the pricing model in finance. The EDI maps to your three largest customers, each with its own document set and its own certification. The shipping rate call. The card-present payment flow and the tokens that live with it. The reporting refresh somebody set up in 2021 that four departments now depend on.
Each of those is a rebuild, a re-test, and — where a trading partner or a payment processor is on the other end — a re-certification on their calendar, not yours. Distributors feel this hardest, because the order path touches ERP, ecommerce, EDI and the warehouse in sequence, and a break anywhere in that chain stops shipping.
Count them before you quote. Walk the list with the people who use the outputs, not the people who maintain the plumbing.
Almost nobody switches a suite in a weekend. You run both systems for a period measured in months, and that period carries three separate costs.
First, double entry: the same transactions keyed into two systems by the same people. Second, reconciliation, because the two sets will disagree and someone has to find out why every time. Third — the one that surprises teams — the people doing the double entry are the same people you need for user acceptance testing and for the decisions in line item one. You cannot spend them twice.
Plan on running through at least one full close, and if the business is seasonal or the reporting is externally audited, plan on a quarter. That is real overtime, real temporary staffing, or real slippage on everything else those people were meant to do. It belongs in the budget as a number, not as a note.
You do not get to leave your history in the old system just because you stopped paying for it.
Under IRS Rev. Proc. 98-25, a taxpayer that keeps records in an automated accounting system must retain machine-sensible records so long as their contents may become material to administering the tax laws, and those records must remain capable of being processed and must reconcile to the books and the return. Replacing the system does not end the obligation — where a change leaves records incapable of being processed, the procedure contemplates notifying the IRS and proposing a plan to restore them. Industry and contract retention obligations stack on top of that.
In practice there are three ways to satisfy this and each has a price:
Migrate the history into the new suite. Expensive, and it lands in a schema not designed to hold it, so the numbers reconcile but the reports do not.
Keep a read-only instance of the old system alive. Operationally simple and quietly permanent — a licence you thought you were cancelling, plus hosting, plus somebody who still knows how to log in.
Extract to a warehouse and rebuild the reporting on top. The most durable answer and a project in its own right, with its own scope and its own schedule.
The cheapest of these by sticker price is usually the one that leaves you unable to answer a question in year three. Price the retention decision before the migration decision, not after go-live when the old contract is already being cancelled.
This is the largest cost and the only one with no invoice attached.
A ten-year-old suite is not a product. It is a product plus a decade of decisions, and most of those decisions were never written down. The custom field that drives the commission calculation. The saved search the whole finance team runs on the second of the month that exists nowhere in any document. The approval step that fires above a threshold because of an audit finding in 2019. The script somebody wrote to work around a limitation the vendor fixed four releases ago, still running, still load-bearing.
Nobody remembers why most of it is there, and several of the people who knew have left. The only way to recover it is to watch the current system do the work and ask why at every branch — a discovery exercise that takes weeks, and the first thing cut when a timeline tightens.
Cutting it does not save the money. It defers it into post-go-live rework, where the same decisions get made under production pressure, by people guessing, at a worse rate. The migration does not fail loudly. It just produces a new system that does 80 percent of what the old one did, and the missing 20 percent turns out to be the part the business actually ran on.
None of this argues against leaving. Sometimes the answer is that the suite stays and you modernise around it — replacement is only one of the six modernisation paths, and the most expensive one to get wrong. What these five line items argue for is counting before you commit. Four things make the total estimable rather than aspirational:
Inventory first, quote second. Count integrations, custom fields and scripts, open transaction types, and reports that leave the building. Those four counts predict the shape of the project better than headcount or revenue.
Ask each vendor which of the five line items their number covers. Most cover implementation and part of data migration. Getting that answer in writing changes what you are comparing.
Decide the retention question early, while the old contract still has leverage in it.
Make one party accountable for the total rather than for their slice. A number that only covers a vendor's own scope is not an estimate of your project.
That last one is where most of the risk actually sits, and it is why CodeStringers structures engagements the way it does. Discovery is where the integration and customisation inventory gets built, and clients pay for it only if they proceed to implementation. Estimates are guaranteed — if the estimate comes in low, CodeStringers absorbs the difference rather than issuing a change order. And Managed Technical Operations covers the period after go-live, when the parallel-running load and the recovered process decisions are still being worked through, so that stretch does not land on a team that is already spent.
Every line above is a cost of leaving. They only mean something next to the cost of staying, which is real, compounding, and much harder to see because it arrives as a slightly worse quarter rather than as an invoice.
Run both columns. Most of the time the honest comparison still favours moving — but it favours moving on a plan that priced the remediation, the integrations, the parallel period, the history and the recovered process knowledge, rather than one that priced the licence and hoped.
That is the difference between buying an application and building an integrated business solution. The suite is the easy part. Everything it has to connect to, and everything it has to remember, is the project.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
NetSuite Alternatives for the Mid-Market: An Honest Comparison (article)
Legacy Software Modernization: How to Fix an Aging System Without a Risky Rewrite (article)
For a mid-market company, from six months to well over a year, and the schedule is set less by the software than by the data remediation and the integration rebuilds. Count the open transaction types with no equivalent in the new system, the integrations the business depends on, and the customizations nobody documented. A migration that skips the counting typically slips by at least one quarter, usually at the point where the data is discovered to be worse than claimed.
Usually only what is needed to operate: open transactions, current balances, active customers, items and vendors, and enough history for comparative reporting. Full history lands in a schema not designed for it and reconciles badly. The record retention obligation is satisfied separately, by keeping a read-only copy of the old system or by extracting the history to a reporting store. Decide which before the old contract is cancelled.
Run both systems through at least one full month-end close, and through a quarter if the business is seasonal or externally audited. Budget the double entry as real hours, name who reconciles the two systems and how often, and recognize that the people doing both are the same people needed for acceptance testing and for the data decisions. Temporary staff for the routine entry is often cheaper than the slippage on everything else.
Migration moves records from one schema to another and is a solved engineering problem. Remediation decides what the records mean: which of two duplicate customers survives, what the old part number maps to, what happens to a partially received purchase order against a vendor you no longer use. Remediation needs people with authority to decide, there are usually thousands of decisions, and it is the largest line in most migrations and the one most often missing from the quote.
One party, for the whole number rather than for a slice. The vendor's estimate covers its own scope. The integration partner covers the joins. Nobody covers the remediation, the parallel running or the process knowledge inside the old customizations unless someone is named. Make a single implementer accountable for the total, ask which of the five line items their number covers in writing, and treat anything not covered as your own budget line.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
