What the IT Bill Looks Like Two Years After an Acquisition

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A COO or VP of Operations at a US mid-market business, 12–24 months post-close on an acquisition, who greenlit the deal expecting synergies but is now staring at an IT budget that has grown, not shrunk, because both companies still run separate CRMs, ERPs, and payroll systems — and nobody has made the consolidation case in numbers the CFO will accept

The IT bill 24 months after an acquisition is almost always higher than the day the deal closed, and the single largest hidden line is not duplicate software — it is the two to four full-time employees quietly absorbed into rekeying data between the two stacks. That headcount never appeared in the integration budget, it compounds every quarter the systems stay separate, and it is the number that unlocks the consolidation business case your CFO has been pushing back on. This post lays out how to assemble the cost of doing nothing in terms a finance team recognizes, how to sequence the spend so the first increment pays for the next, and what to walk into the meeting with.

You are not alone in this. 84% of IT integrations fail or experience significant issues post-merger, and fewer than one in five acquirers is able to improve IT costs and quality post-merger. The deals that recover value do it by making the cost of the status quo visible before they ask for a transformation budget.

Why the IT bill grew instead of shrank

The integration plan at close probably said something like "rationalize overlapping systems within 12 months." What actually happened:

• The acquired entity's CRM contract auto-renewed before anyone made a call on which system wins.
• The ERP consolidation was deferred because the finance team said they could not close books on a half-migrated chart of accounts.
• Payroll stayed separate because the acquired company's PEO contract had a termination penalty.
• Two SSO tenants, two identity providers, two endpoint management suites — because security said "we will unify once the ERP is sorted."
• A handful of analysts started "temporarily" bridging the two systems with spreadsheets. That is now their full job.

None of these decisions were wrong in isolation. Each one deferred a hard call for a defensible reason. The problem is that the deferrals compound, and 50–60% of the initiatives intended to capture M&A synergies are IT-related — which means every month of delay is a month of synergy leakage.

The cost of doing nothing, in four lines the CFO reads

CFOs do not approve budgets against "strategic alignment." They approve against four line items: cash out the door, headcount, exposure, and blocked revenue. Here is how to populate each one from your current environment.

1. Duplicate SaaS and support contracts

Pull every SaaS contract from both entities into one spreadsheet. Flag every category where you have two vendors (CRM, ERP, HRIS, ticketing, BI, endpoint, identity, observability, e-sign, contract lifecycle). For each duplicate, note the renewal date and the annual spend.

The baseline you are competing against is not zero. The average company spends around $135,000 per year on unnecessary software licenses, and that figure increases after a merger because overlapping subscriptions are maintained for months or years. At the top end, Zylo's 2023 SaaS Management Index found the average company wastes around $17 million per year on unused software licenses — a figure that compounds when two stacks merge. Your number sits somewhere on that curve. Find it, don't estimate it.

2. Reconciliation headcount — the line nobody budgeted

This is the one that moves the business case. Walk the floor and ask every analyst in finance, ops, RevOps, and customer success how many hours a week they spend moving data between System A and System B. Include the manager time spent reviewing those reconciliations. Include the month-end crunch.

Benchmarks are brutal here. Across 8–12 fragmented systems, data reconciliation consumes 6–11 analyst hours per week, costing $15,000–$60,000 annually per analyst in fully-loaded cost. In a mid-market company 18 months post-close with two ERPs and two CRMs, it is normal to find the equivalent of 2–4 FTEs permanently absorbed in this work. Fully loaded, that is a line item that often clears $300,000 per year — and it never appears in the IT budget because the people live in finance and operations.

This is the number to lead with. It is defensible, it is observable, and it reframes the conversation from "IT wants to spend money" to "operations is already spending it, just on the wrong line."

3. The expanded audit and compliance perimeter

If you carry SOC 2, ISO 27001, HIPAA, or PCI, every system in scope is a system your auditor tests. Two CRMs means two sets of access reviews, two change-management logs, two vendor security questionnaires, two sets of encryption-at-rest evidence. SOC 2 Type 2 audit costs range from $30,000 to $150,000+ depending on scope, and each additional Trust Services Criterion added increases audit fees by 15–30%. Running two environments directly expands the number of systems in scope.

Add the internal cost: the security engineer and the compliance analyst whose quarters disappear into evidence collection twice. Add the deals that slipped a quarter because a security questionnaire took eight weeks instead of two. These are real numbers you can source from your CISO and your head of sales. (Have your lawyer or auditor confirm the specifics of your compliance obligations — this post is a framing exercise, not legal or audit guidance.)

4. The revenue the patchwork blocks

This is the hardest number to produce and the one that lands hardest. Ask three questions:

• How many enterprise deals in the last four quarters stalled because we could not give the customer a single invoice, a single contract, a single support SLA across both product lines?
• How long is our quote-to-cash cycle on cross-sell deals that touch both entities, versus deals that touch only one?
• How many product bundles has the GTM team proposed and then shelved because the systems could not price or provision them?

Even conservative answers to those three questions tend to dwarf the SaaS duplication line. This is where the 30–50% of anticipated M&A value that McKinsey has shown is lost to slow or ineffective integration actually comes from.

What the integration itself will cost — the shape of the number

Your CFO's next question is "and what are you asking for?" You do not have a quote yet, but you can describe the shape honestly.

Published benchmarks put IT integration costs for deals under $500M at roughly 14% of deal value in recent years. That is the full-scope, do-everything number. The variance within that range is enormous and is driven by four decisions you control:

• Scope: Are you consolidating all overlapping systems or only the two that bleed the most? A focused ERP + CRM consolidation is a fraction of a full stack rationalization.
• Target architecture: Lift-and-shift one tenant into the other is cheaper than designing a new target state. It is also often the wrong answer if neither existing system fits the combined entity.
• Data migration depth: How many years of history must move with full fidelity? Three years of transactional history migrated at line-item detail is a different project from current open balances only.
• Change management load: Training 400 users on a new CRM is a bigger line than the software itself.

The counterweight is the return. Nucleus Research data shows ERP consolidation yields an average ROI of ~150% with payback periods of roughly 12–24 months, driven by lower operating costs, faster financial close, and fewer manual errors. That is the industry average — your number depends on how much reconciliation headcount and duplicate licensing you actually eliminate, which is why Step 1 above matters.

To turn any of this into a real budget line, you need three specifics scoped: (1) which systems are in and out of scope, (2) how much historical data must migrate at what fidelity, and (3) whether you are standardizing on an existing tenant or building a new target. Until those are answered, any number — from a vendor, a consultant, or this post — is a range, not a quote.

Sequencing: strangler-fig vs big-bang

There are two defensible paths. Both work. They fail in different ways.

Big-bang rebuild

Pick the target architecture, run both old systems in parallel for a cutover window, flip everyone over on a weekend. Finance teams sometimes prefer this because the "before" and "after" are clean and the synergy capture shows up in one quarter.

What it is good at: Fast time-to-synergy once live. Clean accounting. Clear project end date.

What it is bad at: Risk concentration. If the cutover fails, you have degraded both entities simultaneously. Change management is brutal — users learn one new system on one date. And if the project slips (and large ERP cutovers slip), the burn rate on the parallel-run period eats the business case.

When to pick it: Smaller user base (under ~200 operational users), relatively clean data on both sides, no live customer-facing dependency on the systems being swapped, strong executive air cover for a hard cutover date.

Strangler-fig increments

Pick the single most expensive duplication (usually CRM or ERP). Design the target. Migrate one business unit, one geography, or one function at a time, running the old and new in a controlled coexistence pattern. Retire the old system module by module. Fund each increment from the savings of the previous one.

What it is good at: Risk is bounded to one slice at a time. The first increment produces a measurable P&L delta you use to fund the second. Change management is distributed across months, not weekends. If an increment goes badly, you roll back one slice, not the enterprise.

What it is bad at: Longer total elapsed time to full consolidation. The coexistence pattern itself costs money — you are maintaining integration glue between old and new during the transition. Finance teams sometimes dislike it because the "before" never fully ends until the last increment lands.

When to pick it: Larger user base, complex data, live customer dependencies, lower appetite for cutover risk, or a CFO who needs to see return on each tranche before funding the next. For most mid-market acquirers 18+ months post-close, this is the realistic answer.

How to phase the spend so increment one pays for increment two

This is the structure that gets approved:

1. Increment 0 (4–8 weeks): Discovery and the baseline. Produce the four-line cost-of-inaction number above with named systems, named contracts, and named FTEs. Design the target architecture at a level sufficient to scope increment 1. This is the smallest ask and the one that produces the artifact your CFO uses to approve everything else.
2. Increment 1: Kill the most expensive duplication. Usually CRM, because the data model is simpler than ERP and the headcount recovery is faster. Target the specific analysts and specific SaaS contracts the cost-of-inaction model identified. Measure actual recovered hours and actual terminated contracts within 90 days of go-live. That delta funds increment 2.
3. Increment 2: ERP or finance system consolidation. Longer, harder, higher return. Done after increment 1 has produced the credibility and the budget line.
4. Increment 3: Everything else. Identity, endpoint, observability, HRIS. Often absorbed into normal renewal cycles once the big two are done.

What the business has to supply is non-trivial and worth flagging upfront to the CFO: a named executive sponsor per increment, clean access to both environments for the integration team, finance ownership of the chart-of-accounts mapping, and protected time from the SMEs on both sides. Projects that fail usually fail here, not on the technology.

How CodeNicely can help

We work with mid-market and enterprise operators on exactly this shape of problem — modernizing legacy stacks, consolidating overlapping systems after an acquisition, and embedding automation into the processes that reconciliation headcount currently covers. The relevant reference here is GimBooks, a YC-backed accounting platform where the engineering problem was reconciling fragmented financial data across formats and sources into a single ledger — the same data-model problem you face across two ERPs. The pattern we used there (incremental migration with a canonical data model behind the scenes, old and new systems coexisting during cutover) is directly applicable to post-acquisition finance consolidation.

If you want help producing the four-line cost-of-inaction model and a scoped increment-1 proposal your CFO can act on, that is a defined engagement — not a full-replacement quote. See our digital transformation and US delivery pages for how we structure these, and the enterprise segment page for how we engage at this stage. Full IP ownership, no vendor lock-in — which matters when you are already untangling one.

The argument to walk into the meeting with

Three sentences:

1. "Our current post-acquisition IT run-rate is $X higher than it should be, and $Y of that is reconciliation headcount in finance and ops, not software — here are the names and the hours."
2. "The industry benchmark for ERP consolidation ROI is ~150% with payback inside 24 months; our first increment targets the CRM duplication specifically because the savings land in two quarters and fund the ERP work."
3. "I am asking for discovery funding to produce the scoped proposal, not for the full program budget — the discovery output is the artifact we use to decide whether to proceed."

That is a conversation a CFO can say yes to. The full-replacement vendor quote on the table today is not.

Frequently Asked Questions

How do I calculate the real cost of running two ERPs post-acquisition?

Add four lines: duplicate license and support spend (pull both contract registers), reconciliation headcount measured in actual analyst hours per week times fully-loaded cost, expanded audit scope (ask your auditor what the second environment adds to the SOC 2 fee and internal evidence effort), and revenue blocked by inability to transact across both systems (ask sales about stalled cross-sell deals). The headcount line is usually the largest and the most under-reported.

Should we consolidate onto the acquirer's system or the acquired company's system?

Neither answer is automatic. The right choice depends on which system better fits the combined entity's future-state processes, data volume, and compliance scope — not which company is bigger. Sometimes the honest answer is a third system, because neither existing platform scales to the merged business. This decision belongs in the discovery phase, not in the kickoff meeting.

How long does post-merger IT consolidation take for a mid-market company?

The elapsed time depends on scope and sequencing. A single-system consolidation (just the CRM, or just the ERP) using a strangler-fig approach typically runs several months per increment; a full stack rationalization across CRM, ERP, HRIS, and identity runs considerably longer and is almost always broken into tranches. The variables that move the number most are user count, historical data migration depth, and whether you are standardizing on an existing tenant or a new target. Those three specifics are what turn a range into a real schedule.

What is the biggest reason post-merger IT integrations fail?

Published research puts the failure or significant-issue rate at 84%, and the pattern across those failures is consistent: integration decisions get deferred past the point where they are cheap, executive attention moves to the next deal, and the business absorbs the cost in headcount instead of fixing the systems. The failure is rarely technical. It is a governance and sequencing failure — which is why the business case has to be built on numbers the CFO already recognizes.

Can we just use integration middleware instead of consolidating systems?

Middleware (iPaaS, custom integration layers) buys time and is often the right short-term move during the first 6–12 months post-close. It is not a destination. Middleware adds its own license cost, its own engineering maintenance, and its own audit scope, and it does not eliminate the reconciliation headcount — it only reduces it. Use it to stabilize, not to avoid the consolidation decision.