Most of the gap between the low and high end of an ERP budget comes from six line items, not from the vendor you pick. They are custom code, data cleanup, integrations, dual-run, the external PMO, and program rescue. Custom code is the largest lever you control: holding it under 10 to 15% of requirements saves 20 to 40% of implementation cost, by ERP Research, an independent research firm. Five of the six are decided before the systems integrator contract is signed. The sixth, program rescue, costs 30 to 50% of the original budget and is the one nobody puts in the approval paper. This article prices each and gives the control lever.
Five of the six items are set before the SI contract is signed
The two ratios that build the headline budget, implementation at 1x to 3x first-year software and a five-year total of 3x to 5x software, are set out in what an ERP program really costs. Those ratios tell you the width of the range. The six items below tell you where inside it you land. For a mid-market tier 2 program published at $300,000 to $3M, that is a tenfold spread, and these items explain most of it.
Each item carries a published range and a lever you can pull. The source and confidence sit in the last column. ERP Research figures are confidence B, meaning two or more independent sources agree. The Costbench and Deliberate Directions figures are confidence C, meaning a single interested source, so they are attributed and treated as planning ranges, not facts.
| Line item | Published range or swing | Control lever | Source (confidence) |
|---|---|---|---|
| Custom code | Swing of 20 to 40% of implementation cost | Cap custom code at 10 to 15% of requirements; make it a steering-committee rule | ERP Research (B) |
| Data cleanup | 10 to 15% of the program budget | Start cleanup before design, with named data owners on your payroll | Costbench (C) |
| Integrations | $10,000 to $50,000 each | Cut the interface count; retire point-to-point feeds before build | ERP Research (B) |
| Dual-run | 12 to 24 months of paying for both systems | Fix the cutover date; shorten the parallel period | Costbench (B/C) |
| External PMO | $5,000 to $20,000 a month | Hold the timeline; move the role in-house after go-live | ERP Research (B) |
| Program rescue | 30 to 50% of the original budget | Commission an independent review at the first warning signs | Deliberate Directions (C) |
The order matters. The first five are choices. The sixth is the price of getting the first five wrong. A buyer who controls custom code, cleans data early, limits integrations, holds the cutover date, and runs a lean PMO rarely needs the rescue line at all.
Custom code is the largest lever a buyer controls
Custom code moves the budget more than any other single item. ERP Research finds that holding it under 10 to 15% of requirements saves 20 to 40% of implementation cost, and the finding holds across tiers. The reason is that custom code costs twice. It costs to build during the program, and it costs again at every upgrade, because standard code upgrades itself and custom code does not.
Put numbers on it. On a $2M implementation, the swing between a disciplined build and an uncapped one is 20 to 40%, or $400,000 to $800,000. That is the difference between landing at $2M and landing at $2.8M, before anything else in this list moves.
The lever is a cap, not a guideline. Set custom code at 10 to 15% of requirements and make the steering committee enforce it, so every custom object has to earn its place against a configured alternative. The pressure to customize comes from inside the business, where a process owner wants the new system to match the old one. The cap is what holds against that pressure. A vendor or SI that proposes heavy custom code at the start has quoted a program that will cost more to run for its whole life, not just to build.
Data cleanup runs 10 to 15% of the budget and lands on your own staff
Data cleanup is the second largest item and the one most often missed in a quote. Costbench, a cost benchmarking site, puts data migration and cleansing at 10 to 15% of the program budget. On a $3M program that is $300,000 to $450,000.
The trap is who pays it. The SI can move data, but it cannot decide which customer records are duplicates, which items are obsolete, or which open purchase orders are real. That work falls on your own finance, supply chain, and master-data staff, and it does not show up in the SI's fee at all. A quote that looks clean on paper can hide a year of your own people's time.
The lever is timing. Start the cleanup before design, not during cutover. Dirty data found at the first mock load is cheap to fix. The same error found at the third mock load, weeks before go-live, forces a choice between slipping the date and going live on bad data. Assign named data owners by domain, on your payroll, and give them time freed from their day jobs. The pillar shows how data problems feed schedule slips, which is where the real cost compounds.
Integrations run $10,000 to $50,000 each, so the count is the number to watch
Each integration between the new ERP and another system costs $10,000 to $50,000 to build and test, by ERP Research. The figure sounds small until you count the interfaces. A company with 12 of them adds $120,000 to $600,000 before any one is tested, and the testing is where integration cost overruns usually hide.
The driver is the number of interfaces, not their individual difficulty. Dual-run makes this worse, because during the parallel period some interfaces have to feed both the old and the new system at once.
The lever is to cut the count before build. Every point-to-point feed that can be retired, consolidated, or replaced by a standard connector removes a line from this list and a risk from testing. Challenge each interface the same way you challenge each piece of custom code: what breaks if it does not exist. Integrations that survive that question are the ones worth paying for.
Dual-run means paying for both systems for 12 to 24 months
Dual-run is running the old and new systems at the same time so you can reconcile them before switching off the old one. Costbench puts the period at 12 to 24 months. For that whole time you pay for both systems, plus the people and the PMO that keep both running, which makes dual-run length one of the most expensive numbers in the budget.
A worked illustration shows how fast a slip moves the total. Suppose a $500M manufacturer with five plants budgets $9M for a tier 1 program and plans a six-month dual-run. During that period it pays three things at once. The new subscription, say $1M a year, is $83,000 a month. Maintenance on the old system, at SAP's 22% of license value on a $2M license base (ERP Research), is $440,000 a year, or $37,000 a month. An external PMO at the top of the range is $20,000 a month.
That is about $140,000 a month, or $840,000 for six months, and it sits in the budget. Now suppose cutover slips and dual-run runs 18 months instead of six. The same $140,000 a month becomes $2.52M. The overrun is $1.68M, or 19% of the $9M budget, before the SI has sent a single change order and before the internal team's extra year is counted.
Nothing in that example happened to any company. It is arithmetic on published figures. It is also why the lever is a fixed cutover date defended by the steering committee, not a dual-run period that quietly extends every time a reconciliation fails. Each month you add costs roughly $140,000 in this illustration, so the schedule is a cost control, not just a plan.
The external PMO runs $5,000 to $20,000 a month, and program rescue runs 30 to 50% of the budget
The last two items are the cost of time and the cost of failure. ERP Research puts an external PMO at $5,000 to $20,000 a month. Over a 36-month tier 1 program, that is $180,000 to $720,000. The PMO is worth having, but it is a monthly meter, so every month the program runs long adds to it. The lever is the timeline and the exit: hold the schedule, and move program-management into your own staff after go-live rather than keeping an external office on retainer.
Program rescue is the sixth item and the one almost no approval paper includes. Deliberate Directions, writing about NetSuite rescues, puts the cost at 30 to 50% of the original budget. It is a single advisory firm's figure, drawn from one product line, so treat it as a planning range rather than a benchmark. On a $9M program, 30 to 50% is $2.7M to $4.5M, which dwarfs any of the five items above.
The reason rescue is so expensive is that it pays for the first five items a second time. A rescue re-does custom code that was built wrong, re-cleans data that loaded badly, and re-tests integrations that were never reconciled, while the PMO and dual-run keep running through all of it. The lever is early detection. An independent review at the first warning signs, open defects rising while the status stays green, mock loads slipping, costs a fraction of a full rescue. Budgeting a small contingency for that review is cheaper than budgeting nothing and paying 30 to 50% later.