Ask what an acquisition integration costs and you get a number for licenses, an SI statement of work, and a go-live date. Ask what it takes and you get a different list, and most of it is not in the budget.
Nobody budgets for the GOLD tenant you have to stand up before real build can start. Nobody budgets for the workstream that exists only to translate the acquired company's data into yours, because their cost centers and job profiles will not line up with yours. Nobody budgets for the command center that has to stay staffed through the first combined month-end close.
I have run more than 15 of these. The line items that decide whether you hit Day 1 are almost never the ones in the original plan.
The reason is structural. The deal model is built by people who price what they can see. A license count is visible. A statement of work has a number on it. A go-live date fits on a slide. The work that fills the gap between signing and a clean Day 1 is harder to see, so it gets left out, and then it shows up anyway, unfunded, in month four.
The data on this is consistent. KPMG reports that 74% of executives name underestimation of integration costs, or overestimation of growth, as the main driver of the gap between projected and actual synergies. That is the gap I am describing. The deal price was modelled fine. That is not where this goes wrong. It is the cost of the work nobody scoped.
Read those together. The integration is where the synergy case is won or lost, and the integration is the part the diligence underfunds. McKinsey finds that 42% of the time, due diligence failed to produce an adequate roadmap for capturing synergies, and that diligence can overlook up to 50% of potential value. The plan that funds the deal is, by the time you sign, already missing half the picture.
So this article leaves the SI invoice alone. It is about the five things I budget for that the deal model usually does not. They are the ones that decide Day 1.
The deal model prices what it can see. The work that decides Day 1 is the work it cannot.
1 The GOLD tenant nobody put on the schedule
Before anyone configures anything, you need a clean environment to configure it in. On a Workday-to-Workday deal, that means standing up a pristine GOLD tenant for the build. On a legacy-to-Workday deal, it is the equivalent build instance, isolated from production so the team can map configurations and load test data without corrupting anything that the business runs on.
This is the first milestone, and it is the one most plans skip straight past. The Gantt chart opens with design workshops in week two. In practice you cannot do meaningful design until you have the tenant to build in, the conversion environment to load into, and the access provisioned for both companies' teams. That setup is real work. It has a lead time. It usually has a cost the deal model never carried.
| The five nobody budgets | Why it is invisible at signing |
|---|---|
| 1. The GOLD tenant | A clean environment has to exist before anyone configures anything. It is infrastructure, so it falls between the licence line and the statement of work |
| 2. The data translation workstream | Their cost centres and job profiles will not line up with yours. This is a workstream, not a mapping exercise, and it exists only because of the deal |
| 3. Testing governance with their team in every cycle | Costs the acquired company's people time their own management did not plan to give up |
| 4. Change management and early power users | Reads as soft until a technically clean deployment fails because the users rejected it |
| 5. A command center that outlives go-live | Budgets end at go-live. The first combined month-end close does not |
The architecture decision underneath it is bigger than the tenant itself. You have to decide early whether to consolidate the acquired company into your existing enterprise tenant, hold them in separate instances for a period, or build a new unified environment. Each path has a different timeline and a different bill. Leave that decision open and every downstream date is a guess.
Every week you spend not locking this down compounds into delay later, and delay near go-live is the most expensive kind there is.
2 The workstream that only exists to translate their data into yours
Acquired companies do not categorize data the way you do. Their cost centers, job profiles, and financial dimensions encode years of their own decisions. None of it lines up with yours on its own.
So I run a workstream whose only job is data translation, and I staff it as its own line item. Do not assume a clean one-to-one mapping exists for core HR or financial data, because it almost never does. One company's single cost center is three of yours. Their job catalog has titles yours has no profile for. Their general ledger carries dimensions you retired years ago.
Here is the part that surprises sponsors. The hard problem sits outside the technology. The mapping turns into a negotiation about whose business logic wins, and that negotiation surfaces decisions the deal model never made. When it stalls, the workstream is rarely what failed. That is the integration finally forcing a call that someone should have made in diligence and did not.
This workstream also gates everything after it. Clean, validated data has to be ready before you enter test cycles. If it is not, the test cycles get spent fixing bad data instead of validating workflows, and you pay for the same cycle twice.
The pattern shows up in the failure data too. Industry analyses put IT problems behind roughly 47% of failed deals, and find that around 80% of value-losing deals went into signing with no coherent technology integration plan. Gartner notes that poorly sequenced IT integration is a major driver of prolonged post-merger timelines. Data translation is the workstream that sequencing lives or dies on, and it is the one most often left off the chart.
3 Testing governance, with the acquired team in every cycle
Testing is where budgets get quietly raided. When a program runs late, the test cycles are the first thing someone tries to compress, because on a status slide they look like effort you can trim. They are how you protect business continuity through a cutover.
I budget for strict testing governance with clear entry and exit criteria for each cycle: unit testing, end-to-end integration testing, and user acceptance testing. A cycle does not start until its entry criteria are met, and it does not close until its exit criteria are. That discipline is what keeps a soft pass from sliding into production where the same defect costs ten times as much and arrives with an audience.
The line item people forget is the people. The acquired team has to participate heavily in every cycle, and that time comes out of somebody's day job. You are pulling their staff off their day jobs to test, which means backfill, travel in some cases, and time their own management did not plan to give up.
Pay for it anyway. They are the only ones who understand their own edge cases: the process with the odd extra step, the customer invoiced differently for a reason that predates everyone in the room. Leave them out of testing and those cases surface in production, where they are no longer test defects. They are outages.
4 Change management, and pulling their power users in early
The acquired employees are losing the systems and processes they know. That is a human cost, and it shows up as a financial one when the people you bought start leaving.
The numbers here should sober up any deal model. MIT Sloan research puts first-year attrition among acquired-company employees at 34%, against 12% for people hired the normal way. EY finds 47% of key employees gone within a year. You can stand up a flawless tenant and still lose a third of the workforce whose knowledge you just paid a premium for.
Change management is the line item that protects against that, and it has to start at kickoff, not in the final month. The single highest-leverage move I make is identifying power users from the acquired company early and pulling them into configuration and testing. Not as a courtesy. As strategy.
Two things happen when you do. The design gets the edge cases right, because the people who know them are in the room. And those same people walk back to their teams as the ones who shaped the new system rather than the ones it was done to. That is how you convert skeptics into champions before go-live, and a technically clean deployment still fails if the users reject it.
You did not buy a tenant. You bought the people who run on it. The integration is the first thing they judge you on.
5 The command center that outlives go-live
Go-live is not the finish line, and budgeting it as one is how programs run out of money exactly when they need it most. The cutover itself takes minute-by-minute sequencing: data extraction, system lockdown, data loading, validation. That is a few intense days. The command center has to live a lot longer than that.
I budget the command center to stay active through the first combined month-end close. That is the real test. Day 1 proves the system turns on. The first combined close proves the books reconcile across two companies that, until weeks ago, kept their numbers in different shapes. The command center stands down only when system stability and adoption are firmly met, and not before.
What it costs is people, on call, for weeks past the date everyone circled on the calendar. What it buys is trust. Every issue resolved fast in the first weeks is a deposit in the account that decides whether the acquired team adopts the system or quietly keeps their old spreadsheet running on the side. I have seen a cutover reported green while the acquired finance team did exactly that, because nobody had earned their trust and the command center had already been disbanded.
Budgets are written to go-live because go-live is the milestone on the slide. The first combined month-end close lands weeks later, and it is the event that decides whether the business trusts the system. Fund the command center to the first clean close, not to the launch date.
What the budget assumes, and what it takes
Put the two pictures next to each other and the gap is the whole article.
This is the same five milestones, read as a budget instead of a sequence. The deal model carries a thin version of each. The work runs long in every one of them. The difference is rarely waste. It is the actual size of the job, and it was always going to come due.
What to do about it
You cannot make these costs disappear. You can decide whether you fund them in the plan or discover them in month four at a premium. The cheap version is the boring one: scope the real work before you sign the SI statement of work, and carry it as named line items rather than a contingency you hope to avoid spending.
The short list I budget every integration around:
- A build environment milestone, GOLD tenant or its equivalent, with a real lead time and a real cost, scheduled before design starts.
- A data-translation workstream staffed on its own, gating entry to test cycles, with time reserved for the mapping arguments that are deferred business decisions.
- Test cycles with hard entry and exit criteria, plus the backfill cost of having the acquired team in every cycle.
- Change management from kickoff, funding the early involvement of acquired-company power users.
- A command center funded to run past go-live, through the first combined month-end close.
None of that is exotic. It is just the part of the work the deal model could not see, written down where it can be funded. The tenant will go live either way. Whether you hit Day 1 with the people and the books intact is decided by the line items nobody budgeted for.
I have run this play across more than 15 acquisitions, Workday to Workday, legacy ERP to Workday, and platform migrations on their own. The full approach is here: how I run an acquisition integration. If you have one coming and want the budget pressure-tested before you commit to a date, book a call or find me on LinkedIn.
Sources: KPMG synergy-realization research on integration-cost underestimation and on deals underperforming their case; McKinsey, Where mergers go wrong and related diligence research; Gartner on IT integration sequencing; MIT Sloan and EY research on post-acquisition attrition. The IT-failure and no-plan-at-signing figures are drawn from aggregated industry analyses. All figures are industry benchmarks, included to frame the pattern, not to model any one deal.