Post-Acquisition System Consolidation: The Case for Your CFO

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

For: A COO or CIO at a UK mid-market enterprise (£50M–£500M revenue) that completed an acquisition 6–18 months ago and is now running two parallel finance, CRM, or ops stacks — watching integration costs mount and the promised synergies slip

The business case your CFO will sign is not the one that lists duplicate Salesforce and NetSuite licences. It is the one that quantifies the 1.5–2 FTE of hidden reconciliation labour sitting inside your finance and ops teams, the compounding UK GDPR Article 30 liability of maintaining two Records of Processing Activities, and the revenue synergies — on average only 34% of those projected at deal signing, arriving 18 months late — that your fragmented stack is actively blocking. Lead with those three numbers and the licence savings become the rounding error, not the argument.

This post gives you the structure of that argument, the sequencing options with their honest risk profiles, and the specifics the CFO will press you on.

Why the obvious business case fails

Most post-acquisition consolidation proposals get rejected not because the CFO disagrees with the direction, but because the numbers on the page are the easy ones. Duplicate SaaS spend is visible, auditable, and — crucially — small relative to the integration programme being requested. If your pitch is £400k of annual licence savings against a £1.8M consolidation programme, you are asking for a four-year payback on a project with execution risk the CFO already distrusts.

The reason that distrust is rational: 84% of IT integrations post-merger fail or experience significant issues, and 83% of data migration projects either fail outright or exceed budgets and timelines. The CFO has either lived through one of these or read about one. You have to beat that prior.

You beat it by making the cost of doing nothing visible on the P&L the CFO is already reading, and by sequencing the work so the first increment pays for the second.

The real cost of running two stacks

There are four cost pools the finance function is absorbing without labelling them as integration debt. Walk the CFO through each.

1. Duplicate SaaS and infrastructure — the visible layer

Start here because it is credible and quick to verify. Two CRMs, two ERPs or finance ledgers, two BI stacks, two identity providers, two expense tools. Gartner finds the average enterprise wastes 30% of its SaaS budget on unused licences, duplicate tools, and shadow IT, and Zylo's 2026 SaaS Management Index puts 51% of enterprise licences as unused. In a dual-stack post-acquisition estate that figure is almost always higher because no one has run the rationalisation exercise yet.

But also be honest about what this number is not. Headline subscription cost understates true SaaS TCO. Hidden integration costs — API charges, iPaaS fees, connector licences — inflate real SaaS TCO by 28–55% above the sticker price, and initial implementation runs 1.5–2.5× the first-year licence for complex deployments. The duplicate licence line in your spreadsheet is a floor, not a ceiling.

2. Hidden reconciliation headcount — the number no one has added up

This is the one that moves the business case. Every month, people in your finance, revenue ops, and customer success functions are manually bridging two systems that do not talk to each other. They are:

• Re-keying customer and vendor master data between the two ERPs
• Reconciling intercompany balances that would be automatic in a single ledger
• Normalising the two sales pipelines into a single board pack
• Running weekly exports from one CRM into the other so account managers can see cross-sell opportunities
• Resolving duplicate customer records at month-end before billing runs
• Hand-mapping the acquired entity's chart of accounts into group consolidation

In a mid-market dual-stack environment this routinely consumes 1.5–2 FTE of fully-loaded cost, spread across six to twelve people doing 10–20% of their week on reconciliation. Nobody has a job title that reads "manual bridge between two ERPs" so the cost is invisible in the org chart. Add it up. At a UK fully-loaded cost of £75k–£110k per FTE depending on function, you are looking at £115k–£220k per year of absorbed labour that disappears the moment the systems merge — and more importantly, 60–80 hours a month of senior finance capacity you get back for actual analysis.

3. UK GDPR Article 30 — the compounding compliance liability

This is the argument the CFO's audit committee will care about even if the CFO does not raise it first. UK GDPR Article 30, preserved in UK domestic law via the Data Protection Act 2018, requires every controller to maintain a written Record of Processing Activities covering every system that holds personal data. Two IT estates means two ROPAs, two sets of data flow maps, two breach-response playbooks, two DPIA registers, and two sets of processor contracts to track.

Every change to either estate — a new SaaS tool, a schema migration, a vendor switch — triggers a re-mapping obligation on both sides. The cost is not the ROPA document itself; it is the DPO or privacy counsel time to keep two parallel records defensible, and the risk that something falls between them.

The enforcement curve has turned sharply. The average ICO fine reached £1.6 million in 2025, up roughly 370% from £675,000 in 2023, with two-thirds of H1 2025 fines issued for UK GDPR breaches. The business case does not need to assume a fine. It needs to acknowledge that each additional month of dual-stack operation increases the surface area and the probability. A lawyer or your DPO should review the specifics for your estate, but the direction is unambiguous.

4. Blocked revenue synergies — the number the deal thesis depends on

Your acquisition memo promised revenue synergies. The CFO signed off against them. They are not landing. KPMG's 2025 survey of 350 integration leaders found acquirers achieved only 34% of projected revenue synergies, arriving on average 18 months late, and McKinsey's long-run data shows 70% of M&A deals fail to achieve stated synergies, with execution and integration — not strategy — the primary cause.

The system fragmentation is a direct, named reason. Cross-sell requires a single customer view. Pricing power requires a single rate card. Procurement consolidation requires a single vendor master. Sales territory rationalisation requires a single pipeline. Every one of those is blocked today by the dual stack.

You will not quantify this to two decimal places. You do not need to. Pull the revenue synergy figure from the original board paper, haircut it to 34%, and present the gap. Then ask: what portion of that gap is attributable to the fact that an account manager cannot see the acquired company's accounts in their CRM? Even a quarter of that figure, in most mid-market deals, dwarfs the entire integration programme.

Sequencing: strangler-fig vs big-bang

The CFO will accept the problem long before accepting the plan. The plan is where most business cases collapse because the author presents a single 18-month programme with a single go-live date. That is the shape of project the CFO has seen fail. Offer a different shape.

Big-bang rebuild

What it is: stand up a single target state (new or chosen incumbent ERP, CRM, data platform), migrate both legacy estates in one cutover, decommission both on day one.

When it fits: both systems are genuinely end-of-life, the acquired entity is small relative to the acquirer, there is a hard regulatory or contractual deadline, or the dual-stack cost is so punishing that an 18-month wait is itself the risk.

Honest downside: this is the profile that produces the 83% data migration failure rate. Scope creeps, business change is attempted in the same window as technical migration, and a single slipped date affects everything. If the migration fails, you have no fallback — the old systems have been decommissioned or starved of investment. The CFO is right to be nervous.

Integration cost shape: EY's study of 229 deals found M&A integration costs range from 1–4% of deal value, with TMT sector median integration costs exceeding 5.5% of target revenue. Big-bang programmes sit at the upper end of that range because the IT work stream is compressed and front-loaded.

Strangler-fig increments

What it is: identify the single most expensive point of fragmentation (usually the finance ledger or the customer master), consolidate that one domain first, prove the savings, use the realised savings to fund the next domain. Named after Martin Fowler's pattern: new system grows around the old, which is removed piece by piece.

When it fits: most mid-market post-acquisition situations where neither legacy stack is burning down, where the business cannot absorb a full-stack change-management event, and where the CFO wants to see payback on increment one before approving increment two.

Honest downside: you live with integration glue — iPaaS, point-to-point APIs, reverse ETL — for the duration, and that glue has its own cost and failure modes. Total elapsed time is longer. If the programme loses sponsorship after increment one, you end up with a worse stack than you started with: two legacy systems plus a half-built new one. This is a real failure mode, not a theoretical one.

Integration cost shape: each increment is independently financeable. First increment typically targets the fastest-payback domain — usually finance consolidation or CRM master data — so the licence savings and FTE recovery from that increment can underwrite the next.

Hybrid: platform-first

What it is: consolidate the data layer first (single customer master, single product master, single chart of accounts in a canonical form) while leaving operational systems in place. Then migrate operational systems onto the clean data foundation one at a time.

When it fits: when the Article 30 / data-governance argument is the loudest part of the business case, when the acquiring and acquired businesses genuinely need to run their operational systems differently for a period (regulatory, geographic, product-line reasons), or when you have no confidence in either legacy stack as the target.

Of the three, IT work streams account for 30–60% of post-merger integration costs regardless of approach, so the sequencing choice is less about the total envelope and more about how risk is distributed across time.

What the business has to supply

The CFO will ask what the organisation has to put in beyond money. Be specific up front — it is a credibility signal.

• A single executive sponsor with authority across both legacy entities. Not a steering committee. One person who can arbitrate when the acquired entity's CFO disagrees with the group CFO on chart-of-accounts design.
• Named process owners for each domain in scope (order-to-cash, procure-to-pay, record-to-report, lead-to-cash), empowered to decide which legacy process wins where they differ.
• Clean master data from both sides. Not perfect — clean enough that duplicates can be detected programmatically. If customer records in one system have no email and no company number, no migration tooling will save you.
• Business time, not just IT time. User acceptance testing, parallel-run validation, and training are where strangler-fig programmes most often slip. Budget 15–25% of affected users' time during the cutover window of each increment.
• A decision on IP and vendor lock-in. If the integration is built on a vendor's proprietary platform you cannot extract from, you have replaced one lock-in with another. This matters more than it sounds when the next acquisition happens.

How to phase the spend

The structure that gets signed: three gates, each with its own business case, each releasing the next tranche of funding.

Gate 1 — Discovery and target state (6–10 weeks). Produce the actual dual-stack cost figure (not an estimate), the ROPA gap analysis, the target architecture, and the increment sequence with payback modelling per increment. Deliverable is a document, not software. This is the gate the CFO approves cheaply because it de-risks everything downstream.

Gate 2 — First increment (typically the domain with fastest payback). Usually finance consolidation or customer master. Scope is one domain, one cutover, measurable savings within 90 days of go-live. Business case for Gate 3 depends on actual realised savings from Gate 2, not forecast.

Gate 3 onwards — subsequent increments, each self-funding against the preceding increment's realised savings and the compounding reduction in Article 30 surface area.

This structure addresses the CFO's actual objection, which is not the money but the execution risk. Three small bets with kill-switches beat one big bet with no exit.

What a cost range actually looks like

Any number quoted without the specifics is misleading. The drivers that move a post-acquisition consolidation programme the most, in roughly descending order of impact:

• Number of operational domains in scope (finance only vs finance + CRM + ops + HR)
• Data quality in both legacy estates, and the volume of history that must migrate vs archive
• Degree of process harmonisation required (same process, different system is cheap; different processes being unified is where most of the cost sits)
• Regulatory environment of the sector (financial services, healthcare, and regulated utilities carry materially higher validation overhead)
• Whether the target state is an existing system being extended, a new SaaS platform being implemented, or a custom build
• Change management capacity in the business — how much user disruption the operation can absorb per quarter

Illustrative only: a UK mid-market acquirer consolidating finance ledgers across two entities with roughly matched chart-of-accounts complexity, 3–5 years of transactional history to migrate, no sector-specific validation regime, and a target of an existing group ERP being extended rather than replaced — this is a different shape of programme to one unifying four domains across two regulated entities with divergent processes and ten years of history. The ranges published by EY (1–4% of deal value for integration, median 5.5% of target revenue in TMT) are a reasonable sanity check on the order of magnitude, not a quote for your situation.

Turning any range into a defensible number requires three specifics: the domain list, the data-migration volume and quality assessment, and the target-state decision. Until those are nailed down, any figure is a placeholder.

How CodeNicely can help

We work with mid-market acquirers on exactly this: the Gate 1 discovery that produces the dual-stack cost figure, the target architecture, and the increment-by-increment business case the CFO will sign. We build on open standards with full IP ownership and no vendor lock-in, which matters when you are consolidating two estates and will likely acquire again.

The engagement that most closely matches this situation is GimBooks, a YC-backed fintech where we rebuilt the accounting data layer and consolidated fragmented ledgers into a single canonical model — the same shape of problem as consolidating two post-acquisition finance stacks, including the chart-of-accounts harmonisation and the historical-data migration tradeoffs. For acquirers whose dual-stack problem is primarily operational rather than financial, our Vahak engagement — unifying a logistics marketplace's master data across what had been multiple regional systems — covers the equivalent ground on the ops side.

Our broader digital transformation and enterprise practice is built around the strangler-fig sequencing described above because, in our experience, that is the model mid-market CFOs actually fund.

The argument, in one page

When you walk into the meeting, lead with these four numbers in this order: (1) hidden reconciliation FTE cost today, (2) the gap between promised and realised revenue synergies, (3) the Article 30 exposure trend given the ICO's 370% fine escalation, (4) the duplicate SaaS line — last, as the confirmation, not the headline. Then offer a three-gate funding structure where the CFO is approving £X for discovery, not £Y for an 18-month programme. That is the business case that gets signed.

Frequently Asked Questions

How long after an acquisition should we start the consolidation programme?

The discovery work should start inside the first 90 days post-close, even if execution is deferred. The reason is Article 30: you have a compliance obligation to document both estates from day one, and that documentation work is 70% of the input to a target-state architecture. Deferring discovery means paying for the ROPA work twice. Execution timing depends on business-change capacity and the acquisition integration plan, but 6–18 months post-close is the typical window where the dual-stack pain becomes undeniable and sponsorship is still fresh.

Should we migrate everyone onto the acquirer's systems or pick the better system per domain?

Default to the acquirer's systems unless there is a specific, defensible reason not to — change management is lower, group reporting is continuous, and vendor relationships are preserved. The exception is where the acquired entity's system is materially more modern or better fit for the combined business; in that case, the acquirer migrates. Mixing per domain (acquirer's ERP, acquired entity's CRM) is appealing in theory and painful in practice because the integration glue multiplies. Pick the smaller number of target systems you can defend.

How do we quantify the hidden reconciliation FTE without doing a full-time study?

Interview six to ten people across finance, revenue ops, and customer success. Ask them to walk through their month-end, their weekly data chores, and the ad-hoc fire drills. Code each activity as either "would exist in a single-stack world" or "only exists because we run two stacks." Sum the second category as a percentage of each person's week, apply fully-loaded cost. The number is defensible to within 20%, which is good enough for a business case. A full time-and-motion study is overkill at this stage.

What drives the cost range for a mid-market post-acquisition consolidation?

The biggest drivers are the number of operational domains in scope, data quality and history volume in both legacy estates, the degree of process harmonisation required, and whether the target state is an existing system being extended or a new platform being implemented. Sector-specific regulation (financial services, healthcare) adds validation overhead. Turning a range into a quote requires a scoped domain list, a data-migration assessment, and a target-state decision — a conversation with us can structure that scoping exercise.

What is the single biggest reason post-merger IT integration programmes fail?

Scope and sequencing, not technology. The 84% failure or significant-issue rate on IT integrations is dominated by programmes that tried to do too much in one go, under-invested in data quality before migration, or lost executive sponsorship between acquisition close and go-live. The strangler-fig increment model exists specifically because it limits the blast radius of any one failure and lets sponsorship renew itself at each gate.