Two companies, one tenant: what nobody budgets for in an acquisition integration

Your side

Ask what an acquisition integration costs and you get those three lines. What it actually takes is a longer list, and most of it isn't in the budget.

I've run more than 15 of these. The reason the gap keeps appearing is structural: the deal model is built by people who price what they can see. 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.

So I'm leaving the SI invoice alone here. These are the five things I budget for that the deal model usually doesn't.

Your side

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's the equivalent build instance, isolated from production so the team can map configurations and load test data without corrupting anything the business runs on.

It's the first milestone, and most plans skip straight past it. The Gantt chart opens with design workshops in week two. In practice you can't do meaningful design until you have the tenant to build in, the conversion environment to load into, and access provisioned for both companies' teams. That setup has a lead time, and it usually has a cost the deal model never carried.

Your side

So I run a workstream whose only job is data translation, and I staff it as its own line item. Don't assume a clean one-to-one mapping exists for core HR or financial data, because it almost never does.

What surprises sponsors is where the hard problem sits. The mapping turns into a negotiation about whose business logic wins, and that negotiation surfaces decisions the deal model never made. When it stalls, it's usually because the integration is finally forcing a call someone should have made in diligence.

Everything after this workstream depends on it. Clean, validated data has to be ready before you enter test cycles. If it isn't, the test cycles get spent fixing bad data instead of validating workflows, and you pay for the same cycle twice.

Your side

Testing is where budgets get 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. In fact they're how you protect business continuity through a cutover.

I budget for strict testing governance, with entry and exit criteria for each cycle: unit testing, end-to-end integration testing and user acceptance testing. A cycle doesn't start until its entry criteria are met and doesn't close until its exit criteria are. That discipline keeps a soft pass from sliding into production, where the same defect costs ten times as much and arrives with an audience.

10×what the same defect costs once it slides into production

Your side

Change management is the line item that protects against that, and it has to start at kickoff rather than in the final month. The highest-leverage move I make is identifying power users from the acquired company early and pulling them into configuration and testing. I do it as strategy, and I budget for it that way.

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 go back to their teams as the ones who shaped the new system rather than the ones it was done to. That's how skeptics become champions before go-live, which matters because a technically clean deployment still fails if the users reject it.