Why Enterprise Integration Projects Blow Past Budget in the Last 20%

Most enterprise integration projects look healthy for a long time. Interfaces get built and status reports stay green. Then the systems start talking to each other with real data, and the budget starts to slide. The overrun feels sudden, but it usually comes from work that was hidden or postponed earlier in the plan.

For B2B SaaS buyers and vendors, this matters more every year. A new CRM or billing platform is rarely useful until it’s connected to the rest of the stack. That connection work is where estimates break. This guide explains what the last 20% of an integration project contains, why costs pile up there and how to move that risk earlier.

TL;DR

Enterprise integration projects tend to overrun near the end because that’s when systems first meet real data at real volume. Integration testing often starts late, so defects found in the final phase cost more to fix. Data migration exposes quality problems that nobody measured at the start. Cutover and go-live bring work that rarely appears in early estimates, such as rehearsals and weeks of support after launch. Progress reports also overstate completion, because “built” is counted as “done” long before anything works end to end. The fix is to pull integration risk into the first weeks of the project. Budget the final phase as its own piece of work, and watch for warning signs at the midpoint.

What the last 20% of an integration project actually contains

The last 20% of an enterprise integration project is rarely just finishing touches. It’s the phase where separate pieces of work become one working system. Most of the hard questions get answered here for the first time.

A typical final phase includes end-to-end testing across every connected system. It includes full loads of production data and the fixes that follow. It also includes performance testing at real volumes, security reviews, user acceptance testing, cutover rehearsals and the launch itself. After launch comes a support period, often called hypercare, when the project team fixes problems in production.

Some of the final-phase work is invisible until someone asks for it. Error handling and alerting often get deferred because they don’t show up in a demo. In an enterprise integration project, they matter a great deal, because a silent failure between 2 systems can corrupt data for days before anyone notices. When security or operations teams review the design near launch, those gaps turn into new work with a fixed deadline.

None of this work is new or unknown. The problem is that most of it depends on everything else being finished first. A team can’t test a full order-to-cash flow until the CRM, the billing system and the ERP connections all exist. So the work queues up at the end, and any problem it reveals has to be fixed under deadline pressure.

The phrase “last 20%” is a rule of thumb. No study marks the exact point where trouble starts. Some projects hit trouble at 70% complete, others at 95%. What stays the same is the pattern: the work that proves the systems fit together is scheduled late, and that’s where the surprises land.

How large IT project cost overruns really get

The size of a typical cost overrun is well documented. Research from McKinsey and the University of Oxford on more than 5,400 IT projects found that large IT projects run 45% over budget on average. They also run 7% over time and deliver 56% less value than predicted. The study defined large projects as those with initial budgets above $15 million. A later McKinsey and Oxford Global Projects analysis expanded the database to 6,003 IT projects completed between 2001 and 2017. Across projects of all sizes, average cost overruns were 75%, schedule overruns were 46%, and benefits came in 39% below forecast.

The same research found that duration matters. Every extra year a project ran added about 15% to its cost overruns. That’s a strong argument for shorter phases, because long projects give more time for hidden work to grow.

Averages also hide the worst cases. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27%. Their paper on IT project risk showed that 1 in 6 projects was a “black swan,” with cost overruns averaging 200% and schedule overruns of almost 70%. In other words, most projects miss by a moderate amount, but a meaningful share miss by a lot.

Integration work is especially exposed to these tail risks because its tasks depend on each other. Each new system adds connections to the ones already in scope, and each connection has its own owner and release schedule. A delay in one system’s test environment can stall testing for every flow that passes through it. Those dependencies help explain how a small slip in one place can grow into a large overrun across the whole program.

These studies cover IT projects broadly, not only integration work. Still, enterprise integration projects carry the traits that drive large overruns. They involve many systems with different owners, and they rely heavily on late testing. That puts integration work at real risk of landing in the fat tail.

Why integration testing arrives too late

Testing across systems is a major reason costs spike near the end. Each team tests its own component early, but the full flow across systems often isn’t tested until everything is built. By then, a defect may touch several systems and several vendors at once.

The cost of late discovery is old news in software. A study commissioned by NIST estimated that inadequate software testing cost the US economy about $59.5 billion a year. It also found that over half of errors weren’t found until late in development or after release. Better, earlier testing could have removed about a third of that cost. The study is from 2002, but the pattern it describes still matches how integration defects behave.

HealthCare.gov is a well-known public example. During congressional hearings in 2013, contractors testified that integrated end-to-end testing of the full system ran only in the last 2 weeks before the October 1 launch. One contractor said months of testing would have been better. The site struggled badly at launch.

Shared test environments add their own delays. Each connected system needs a test instance with the right version and usable data. In a large enterprise integration project, those instances are often owned by different teams with different refresh schedules. If one environment is down or out of date, the whole end-to-end test stops. Test data adds another hurdle, because copies of production data may need masking before they can be used outside production.

Late integration testing is rarely a choice anyone makes on purpose. It happens because test environments arrive late, because partner systems aren’t ready or because each team assumes someone else owns the end-to-end test. Each of those reasons can be fixed early, but only if someone owns the problem from the start.

Data migration surprises that surface at the end

Data migration is another major source of late overruns. Teams often plan migration as a technical task: extract, transform and load. In practice, the hard part is the data itself. Duplicate customers and years of manual workarounds show up when real records move into the new system.

These problems stay hidden because early testing usually runs on clean sample data. The sample works, so the estimate looks fine. Then the first full load fails validation, reconciliation reports don’t match and business users find records they no longer trust. Each round of fixes means another load and another sign-off.

Reconciliation is where the time goes. After each trial load, someone has to prove that record counts and balances match between the old and new systems. Business owners have to decide what to do with records that don’t fit, and those decisions often need sign-off from finance or compliance. Plan for several trial loads, and name the business owner for each data domain before the first one runs.

Data meaning is a separate problem from data quality. MuleSoft’s research, reported by ITPro Today, noted that integration teams struggle to understand what data is exchanged and whether it means the same thing on both sides. A “customer” in the CRM may not match a “customer” in billing. An “active” contract may mean different things to sales and finance. Those mismatches rarely appear in design documents, but they break reports and workflows once real records move.

The business impact can be severe. Birmingham City Council’s move from SAP to Oracle left it unable to file auditable accounts and, for a period, unable to detect fraud. The Oracle program, initially estimated at £19 million, was forecast at £144.4 million by January 2026. A separate Audit Reform Lab estimate put the wider financial loss at roughly £216.5 million through April 2026, including forgone efficiency savings.

Interface mismatches between systems

Every integration point is an agreement between 2 systems about what data moves and in what format. Problems start when those agreements are informal. One team changes a field name or a date format, and a downstream system breaks weeks later during testing.

SaaS platforms add their own constraints. API rate limits and version changes both affect how an integration behaves at real volume. A design that works for 100 test records may fail for 2 million production records. These limits are usually documented, but teams often don’t check them against expected volumes until late.

The scale of the integration landscape makes this harder. MuleSoft’s 2023 research found organizations used an average of 1,061 applications, with up to 70% not properly integrated. Organizations spent an average of $4.7 million building custom integrations. Each custom connection is another agreement that can drift.

Error handling is often left until the end. Networks drop requests and systems time out, so integrations need to retry. If an order message is retried after a timeout, a system that isn’t built for it may create the order twice. Designing each interface so that a repeated message has no extra effect takes planning. Retrofitting it after testing finds duplicate records is far more expensive.

Contract testing is one practical answer. The Pact documentation describes contract testing as a way to test each integration point on its own. Each application’s messages are checked against a shared contract, so the test doesn’t need every system running at once.

The idea behind it is older than the tooling. Martin Fowler’s article on consumer-driven contracts explains that the systems that use a service define what they need. The provider then checks that it still meets those needs. Breaking changes get caught when they’re made, so teams don’t find them weeks later.

Cutover, go-live and hypercare costs

Cutover is the moment the business switches from the old system to the new one. It’s often planned as a single weekend, but the work behind it takes much longer. Teams need a runbook, data freeze rules, rehearsals, go/no-go criteria and a tested rollback plan.

Cloud providers treat this phase as real work. AWS’s guide to cutover runbooks describes the runbook as a key artifact for the cutover stage, alongside a pre-migration checklist and a rollback plan. Each task needs a named owner and a time window. Building and rehearsing that plan takes weeks, and it’s often missing from the original estimate.

TSB’s 2018 migration shows what happens when this phase goes wrong. The UK bank moved customer data to a new platform, and customers were locked out of services for weeks. TSB reported £330.2 million in post-migration costs and foregone income for 2018. The FCA and PRA later imposed a £48.65 million fine, and it took until December 2018 to return to normal service.

The cutover strategy also shapes cost. A big-bang switch moves everyone at once, which keeps the plan simple but leaves little room for error. A phased approach moves one region or business unit at a time. A parallel run keeps both systems live for a period so results can be compared. The safer options cost more in the short term, so the choice should be made early and priced into the budget.

The weeks after go-live also cost money. Google’s site reliability guidance on reliable product launches treats a launch as a process with checklists and reviews. For integration projects, that means budgeting for a hypercare period with the project team still in place. If the team rolls off on launch day, every production issue becomes a new, unplanned cost.

Why progress reports hide the problem

Status reports often look green until late in an enterprise integration project. That’s because most progress measures count work produced. They rarely check whether the work has been proven. An interface is marked complete when it’s built and unit tested, even if it has never exchanged data with the real system on the other side.

Software teams have joked about this for decades. The “ninety-ninety rule” is credited to Tom Cargill of Bell Labs. It says the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90%. The joke works because the last stretch includes all the work that couldn’t be finished until everything else existed.

HealthCare.gov showed how this plays out when nobody owns the whole system. Nextgov’s account of the congressional hearings reported that no senior executive at CMS was named as the point person for integrating the system’s components. Contractors told lawmakers their own components had passed unit tests. Without a single owner for the whole flow, each team could report its part as done while the system as a whole wasn’t ready.

The fix is to change what “done” means. An interface should count as complete only when it has worked in an end-to-end test. That makes reports look worse earlier in the project, but it gives leaders an honest view while there’s still time to act.

Reporting can follow the same rule. List every business flow the enterprise integration project must support, such as quote to cash or hire to payroll. Then report how many of those flows have passed a full test with production-like data. That number starts low and moves slowly, which is exactly why it’s useful.

Contract and scope dynamics in the final phase

Commercial terms can make the last 20% more expensive. Late in a project, the client has little choice but to finish with the vendors already in place. Every new requirement or fix becomes a change order, and the client has less room to push back on price.

Changing requirements make this worse. The GAO’s review of HealthCare.gov found that new and changing requirements drove cost increases. KFF Health News reported that the GAO report put the total cost of the site and its supporting systems at $840 million. One follow-on contract grew from $91 million to more than $175 million. Late changes add work, and they also force retesting of work that was already finished.

Customization is another late cost driver. Birmingham City Council planned to run Oracle with minimal changes but built several customizations, including a banking reconciliation system that failed to work properly. The Register reported that the Birmingham Oracle project was forecast to cost £144.4 million, up from an initial estimate of £19 million with a £1 million contingency. Each custom piece added integration and testing work that only became visible near launch.

Team changes add a quieter cost. Vendors may move their strongest people to new projects once the build phase ends. The engineers who designed the interfaces may be gone by the time integration defects appear. New staff then spend paid time learning the system before they can fix anything. Key-person clauses and a planned handover from build to support teams reduce that risk.

With fixed-price contracts, the dispute usually shifts to what counts as in scope. When integration testing reveals that 2 systems need a data mapping nobody specified, both sides may disagree about who pays. Clear interface definitions and acceptance criteria at contract signing reduce those disputes later.

How to pull integration risk into the first 20%

A reliable way to reduce late overruns is to do the riskiest integration work first. That means proving the systems can talk to each other before building every feature on top of them.

1.     Build a thin end-to-end slice early. Pick one real business flow, such as a new customer moving from CRM to billing to ERP. Make it work across every system within the first few weeks.

2.     Test with production-like data from the start. Profile real data early and load a full copy into a test environment as soon as possible. Clean sample data hides the problems that matter.

3.     Agree on interface contracts in writing. Define each integration point’s fields, formats and error handling, and test against those contracts every time code changes.

4.     Check platform limits against real volumes. Compare API rate limits and bulk-load limits with expected daily and peak volumes before the design is final.

5.     Name a single owner for end-to-end integration. One person or team should own whether the full flow works, across all vendors and systems.

6.     Rehearse cutover more than once. Run full dress rehearsals with timed steps and a tested rollback, and treat the results as data for the real cutover plan.

Start with the hardest flow. Teams often pick a simple flow first to build confidence, but the risk sits in the flows that touch the most systems or the messiest data. Proving one of those early tells the enterprise integration project far more about its real budget than a quick win would.

This approach makes the final phase smaller and more predictable. Problems still appear, but they appear when there’s time and budget to fix them.

How to budget for the last 20%

Many cost overruns start with an estimate that treats the final phase as a short wrap-up. A better approach is to budget it as a project in its own right, with named owners and its own contingency.

Track spending against each of these lines separately once the project starts. A single blended budget line hides where money is going. When testing or migration costs climb faster than planned, separate lines make that visible to sponsors early, while there’s still time to add reserve or cut scope.

Estimates improve when they start from outcomes instead of plans. Flyvbjerg’s work calls this taking the outside view, a method known as reference class forecasting. Instead of building the budget only from a task list, look at how similar projects actually turned out, then adjust. If past enterprise integration projects at your company spent far longer on testing and migration than planned, the next estimate should reflect that history.

Contingency should follow risk. A project with many systems or poor data quality needs more reserve for the final phase than a simple point-to-point integration. Hold that contingency at the program level, so it isn’t spent early on features.

Reforecast at the midpoint. Once the first end-to-end flow has run with real data, the team knows far more about defect rates and data quality than it did at the start. That’s the right moment to revisit the final-phase budget, before most of the money is spent.

Shorter releases help too. When each release has its own end-to-end test and its own data migration, the risk is spread across the program instead of saved for one final push. That also fits the research finding that longer projects overrun more.

Warning signs at the midpoint

Most late overruns send signals well before the final phase. Leaders who know what to look for can act while there’s still room to change course.

Watch for test environments that keep slipping, because end-to-end tests can’t start without them. Watch for migration plans that still rely on sample data halfway through the project. Watch for interface specifications that say “to be confirmed” on key fields, or vendors that won’t commit to API versions.

A short midpoint review can test for these signs. Ask the team 4 questions, and ask for evidence with each answer:

•       How many end-to-end business flows have passed with production-like data?

•       When did the last full trial data load run, and what failed?

•       Which interfaces still have open questions about fields or formats?

•       Has the cutover plan been rehearsed, and how long did it take?

Reporting patterns matter as well. If every component is green but no end-to-end flow has run, the project isn’t as far along as it looks. If the cutover plan is still a single slide at the midpoint, that phase is likely to cost more than planned. If the go-live date hasn’t moved despite late test environments, the schedule is probably absorbing risk that will surface later as cost.

When these signs appear, the cheaper path is often to slow down and prove the integration before adding more features. That feels like losing time. In practice, it often saves the budget that would otherwise disappear in the last 20%.

What this means for SaaS buyers and vendors

Many enterprise integration projects now connect at least 1 SaaS platform. That changes who controls key parts of the work. The buyer owns the project, but the SaaS vendor controls the API and its release schedule.

Buyers should ask about integration before they sign. Request the vendor’s API limits, and ask how much notice they give before breaking changes. Ask whether the sandbox behaves like production at real data volumes, because a sandbox with lower limits can hide problems until launch. Ask who on the vendor’s side will be available during cutover and hypercare, and put that commitment in the contract.

Vendors carry part of the risk too. A failed implementation can turn into churn, even when the core product works. SaaS vendors that publish stable APIs with realistic sandboxes make their customers’ final phase smaller. Implementation teams that stay engaged through the first weeks after launch help the customer reach real use instead of stalling at go-live.

For both sides, the useful question is the same: what has to be true for the final phase to be boring? An enterprise integration project that runs end-to-end tests early and rehearses its cutover usually gets there. One that saves all of that for the last month usually doesn’t.

Final thoughts

Enterprise integration projects don’t overrun at the end by accident. The final phase is where integration testing, data migration and cutover finally happen, and those are the activities most likely to reveal hidden problems. Large studies show that IT projects regularly overrun, and that a meaningful share overrun by a great deal.

The answer is to change when the hard work happens. Prove one end-to-end flow early with real data. Then budget the final phase as real work instead of a wrap-up. Projects that do this still meet surprises, but they meet them early, when they’re cheaper to fix.

FAQs

Why do enterprise integration projects go over budget near the end?

The final phase is when systems first run together with real data at real volume. End-to-end testing and data loads often reveal problems that earlier testing missed. Fixing them late costs more and often affects several systems at once.

What does the last 20% of an integration project include?

It usually includes end-to-end testing and full data loads, performance testing, user acceptance testing, the launch and a hypercare period. Most of this work depends on all components being finished first.

How much do large IT projects typically overrun?

McKinsey and Oxford research on more than 5,400 IT projects found that large projects run 45% over budget on average. A separate study found that 1 in 6 IT projects had cost overruns averaging 200%.

Is the last 20% rule based on research?

It’s a rule of thumb. Research shows that defects are often found late and that IT projects often overrun. The exact point where trouble starts varies by project.

Why is integration testing often left until late?

Integration testing needs all connected systems and a shared test environment. Those often arrive late, or no one owns the end-to-end test. Teams test their own parts early and assume the full flow will work.

How does data migration cause cost overruns?

Real data contains duplicates and gaps that sample data hides. Each failed load needs fixes before the next attempt. Several rounds can add weeks to the final phase.

What is hypercare after go-live?

Hypercare is a support period right after go-live, when the project team stays in place to fix production issues quickly. If it isn’t budgeted, those fixes become unplanned costs.

What is a cutover plan?

A cutover plan sets out every step needed to switch from the old system to the new one. It includes task owners, timing, go/no-go criteria and a rollback plan. It should be rehearsed before the real cutover.

How can we detect integration problems earlier?

Build one thin end-to-end flow across all systems early in the project. Test it with production-like data, and run contract tests on each interface whenever code changes.

What is contract testing in integration projects?

Contract testing checks that each system sends and receives messages that match a shared contract. It catches breaking interface changes when they’re made, instead of weeks later.

How much contingency should an integration project have?

There’s no single right percentage. Size contingency based on risk, such as the number of systems and the state of the data. Hold it at the program level so it isn’t spent early.

Do fixed-price contracts prevent late overruns?

Not fully. They shift disputes to what counts as in scope. Clear interface definitions and acceptance criteria at signing help reduce arguments when late problems appear.

What are early warning signs of a late overrun?

Common signs include slipping test environments, migration plans built on sample data and vague interface specifications. Green component reports with no end-to-end test are another warning.

Does agile delivery solve the last 20% problem?

It helps when each release includes real end-to-end testing and full data loads. Agile teams can still defer integration work, so the practice matters more than the label.

Who should own end-to-end integration?

One named person or team should own whether the full business flow works across all systems and vendors. Without that owner, each team can report its part as done while the whole system isn’t ready.