Consolidating Systems After an Acquisition Without Freezing Operations

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

For: COO or CIO at an Indian mid-market enterprise that completed an acquisition six to eighteen months ago and is now running two parallel ERP, payroll, or CRM stacks — paying for both, reconciling data manually, and watching the integration lag erode the synergies the board was promised

If you are running two ERPs, two payrolls or two CRMs six to eighteen months after closing a deal, the right answer is almost never a big-bang cutover and almost never "wait another quarter." It is a strangler-fig sequence that retires one subsystem at a time — master data first, then transactional modules, then reporting — while both stacks keep running. The reason your IT vendors keep quoting a three-to-six-month freeze is that a freeze is easier to scope than an incremental migration. The reason your CFO keeps deferring is that nobody has put the cost of waiting on the same page as the cost of moving. This post gives you both.

The cost of doing nothing, assembled into one number

Every post-acquisition CIO we talk to can list the pain points. Very few have added them up in a format a CFO will accept. Do that first, because the business case for consolidation is almost always won or lost on the "status quo" column, not on the "migrate" column.

Here are the line items that actually belong in the status-quo column for an Indian mid-market acquirer running parallel stacks:

1. Duplicate licence, hosting and support contracts

Two ERP subscriptions. Two payroll platforms. Two CRM seat counts. Two AMC lines with two implementation partners. Two cloud tenants or two on-prem support contracts. ERP Research flags this as one of the top cost-overrun drivers in post-merger IT, separate from the migration project itself — a line that quietly runs for the full duration of the delay. For a mid-market Indian group with 300–800 users across both entities, the duplicate-stack carry alone typically lands in a seven-figure monthly range before you count the people.

2. Reconciliation headcount

This is the line most CFOs underestimate because it is distributed across functions. Finance has two or three people doing nothing but matching GL entries between the two books. The GST team has someone exporting from both ERPs into Excel every month because the HSN masters and vendor masters don't align. HR runs two payroll cycles and a reconciliation sheet to produce a group-level cost report. Sales ops maintains a shadow spreadsheet because neither CRM is the system of truth. None of these people were hired for this; they were absorbed into it. Add them up honestly — including the senior-manager time spent reviewing their work — and the number is usually larger than the duplicate licence line.

3. Audit and statutory exposure

This is where the risk column gets uncomfortable. Under Section 128 of the Companies Act 2013, failure by the MD, CFO or whole-time director (Finance) to maintain proper books of accounts is punishable with imprisonment of up to one year or a fine of ₹50,000–₹5,00,000. Non-reconciled dual books of a newly merged entity sit uncomfortably close to that line. GST filings based on mismatched vendor and HSN masters produce ITC mismatches that compound across quarters. We are not giving legal advice here — your auditor and company secretary need to assess your specific exposure — but the point for the board paper is that the risk is not zero and it grows with time.

4. Synergies the board was promised and the deal thesis assumed

This is the number the CEO cares about. McKinsey research shows 30–50% of anticipated M&A deal value is lost through slow or ineffective integration. IT consolidation synergies realise at only 65% of their announced value over 9–24 months — the lowest realization rate of any cost-synergy category. And Indian acquirers have a specific problem here: McKinsey India finds that one-off Indian acquirers deliver only 30–50% of announced synergies within 24 months, versus 45–75% for programmatic acquirers such as Tata, Reliance and L&T. The gap is driven largely by IT integration delays.

5. Revenue the current state blocks

This one is deal-specific. If the acquisition was supposed to cross-sell the target's SKUs through the acquirer's channel, and the two product masters still don't talk to each other, that revenue is not showing up. If the acquired entity has a better collections workflow but it lives in a CRM nobody else can see, DSO improvements are stuck on one side of the house. Put a number on the top two or three of these. They are usually larger than everything above combined.

Assemble these five lines into a single monthly burn rate. Then multiply by the number of months your current plan implies before the second stack is retired. That is the number the migration project is competing against — not zero.

Why the big-bang quote keeps showing up

When an SI quotes you a six-month freeze, they are optimising for their delivery risk, not yours. A big-bang cutover has a clean scope: lift the data, map the schema, run two UATs, pick a weekend, cut over. It is easy to price, easy to staff with a fixed team, and easy to close out.

The problem is that 84% of post-acquisition IT integrations fail or experience significant issues, and Gartner reports 83% of data migration projects fail outright or exceed their budget and timeline. The failure modes of a big-bang are also the worst ones: order fulfilment stops, invoices don't generate, payroll misses a cycle, GST filing dates get hit mid-cutover. For an operating business with customers and statutory deadlines, this is not an acceptable risk profile for a project with a one-in-six base rate of going cleanly.

The alternative is harder to scope and harder to sell, which is why it rarely leads the pitch.

The strangler-fig sequence for post-acquisition consolidation

The strangler-fig pattern — originally a software architecture idea — maps unusually well onto post-merger system consolidation. You wrap the two existing stacks in an integration and data layer, then retire capabilities from the stack you are sunsetting one at a time, routing each one to the surviving stack. Both systems keep running throughout. Users don't see a cutover; they see modules quietly moving.

A sensible sequence for an Indian mid-market consolidation looks like this:

Phase 0: Master data reconciliation and the integration layer (weeks, not months)

Before anything moves, you need one version of the customer master, vendor master, item/HSN master, chart of accounts and employee master. This is the single highest-leverage work in the entire programme. 41% of post-merger integrations suffer from incompatible IT systems, and 32% identify data integration as the single biggest challenge — and both problems collapse into the master-data layer. Build a reconciled master-data store, with clear rules for which source wins when they conflict, and expose it to both ERPs via APIs or a lightweight middleware. This is also where the dual-licence clock starts to slow down, because the finance team can finally produce a clean group-level report without manual Excel work.

Phase 1: Retire the easiest subsystem first

Not the biggest. The easiest. Usually this is payroll, or CRM, or a specific module like fixed-asset management. Pick the one with the fewest integration points, the smallest user base and the lowest statutory risk. Migrate it fully to the surviving stack, decommission the duplicate licence, and bank the saving. This phase has two jobs: prove the sequence works, and free up budget for Phase 2 from the licence saving itself.

Phase 2: Transactional modules, one at a time

Order-to-cash, procure-to-pay, inventory, manufacturing — in whatever order makes sense for your business cycle. The rule is: never cut over a module during its peak period. Don't migrate OTC in March. Don't migrate inventory before a festive push. Don't migrate payroll in the month a bonus is due. Each module moves on its own weekend, with the integration layer handling the handoff from the retiring stack.

Phase 3: Reporting, analytics and the final decommission

By the time you get here, the surviving ERP is doing most of the real work and the retiring one is mostly a historical archive. Migrate the reporting layer, run both systems in parallel for one full statutory cycle (one quarter minimum, often one full year-end), and then formally decommission. The AMC and licence lines come off the P&L. The reconciliation headcount gets redeployed.

What the business has to supply

Vendors rarely tell you this upfront, and it is the single biggest determinant of whether the programme runs on time. From the acquirer and the acquired entity, you need:

• A single accountable executive on each side — usually the CFO or COO, not the CIO — who can arbitrate when the two master-data rules conflict. Most delays we see are not technical; they are because nobody has the authority to decide whose customer master wins.
• Documented current-state workflows for the top ten business processes on each side. Not wiki pages — actual walkthroughs with the people who do the work. The acquired entity usually has undocumented workarounds that will break on migration if nobody surfaces them.
• A statutory calendar covering GST, TDS, PF, ESI, advance tax, board meetings and audit windows for both entities. Every cutover date gets checked against this calendar before it is committed.
• Clean historical data for at least the last two financial years, or an explicit decision to leave older data in the retiring system as a read-only archive. Trying to migrate ten years of transactional history is usually where timelines double.
• User-acceptance testers from both entities, released from day-job responsibilities for the UAT windows. If UAT is done by whoever is free that week, you will discover the real issues in production.

How to think about the cost and timeline

We will not quote a number here, because the number depends on specifics we cannot see from a blog post. But we can tell you what drives it, which is more useful anyway for the board paper.

The cost of a strangler-fig consolidation is driven, in roughly this order, by: (1) the number of modules in scope and whether they include manufacturing or multi-location inventory, which are the two most complex, (2) the number of external integrations — banks, GSPs, logistics partners, marketplaces, customer EDI feeds — because each one has to be rebuilt or rerouted, (3) the volume and cleanliness of historical data to be migrated, (4) the number of custom reports and workflows in the retiring system that users genuinely need preserved versus ones they say they need but haven't opened in a year, and (5) the degree of process harmonisation the business wants to do at the same time. The last one is the biggest variable: if you try to redesign processes and migrate systems in the same sweep, you double the timeline.

Timeline is driven by the same factors plus the statutory calendar and the pace at which the business can absorb change. A sensible rule of thumb is that each major module takes a quarter to migrate cleanly in a strangler-fig sequence, with the first module taking longer because the integration layer is being built alongside it. A six-module consolidation is therefore not a six-month programme and not a three-year programme; it is somewhere in between, and the specifics decide where.

What is reasonably well-established is that ERP implementations that succeed deliver an average ROI of ~150% with a payback period of 12–24 months (Nucleus Research). That is before counting the dual-licence and reconciliation-headcount savings that a post-acquisition consolidation also delivers — savings that start accruing from Phase 1, not from the end of the programme.

Illustrative only — your numbers will differ: for a mid-market group with two ERPs, roughly 500 users total, 15 external integrations, two years of history to migrate and no process-redesign scope, a phased consolidation that retires the first module in the first quarter and the last in the sixth or seventh will typically pay for its first phase from the licence and headcount savings of that same phase. Every assumption in that sentence moves the number. Change the integration count to 40, add manufacturing, or layer in a process redesign and you are in a different programme.

To turn any of this into an actual quote, three things have to be scoped: the exact module and integration inventory on both sides, the historical-data cut-off decision, and the statutory calendar that constrains the cutover windows. Without those, any number anyone gives you — including ours — is a guess.

How to phase the spend so Phase 1 funds Phase 2

This is the structure that usually gets a sceptical CFO to approve the programme:

1. Fund Phase 0 (master data and integration layer) from the current reconciliation-headcount budget. You are not adding cost; you are redirecting spend that is already happening manually into a system that will eliminate the need for it.
2. Pick a Phase 1 module whose annual duplicate-licence cost exceeds its migration cost. Payroll and CRM often qualify. The licence saving in year one pays for the migration, and the headcount freed from reconciliation funds Phase 2.
3. Commit to each subsequent phase only after the prior phase has banked its promised saving. This is the governance mechanism that makes the programme defensible to the board. Nobody is being asked to approve the whole number upfront.

This structure also protects you against the base-rate failure risk. If Phase 1 goes badly, you have lost one module's worth of budget, not the whole programme. If it goes well, the next phase is self-funding and the argument gets easier each time.

How CodeNicely can help

We have done this kind of work most visibly for GimBooks, the YC-backed accounting SaaS platform, where the problem was analogous even though the context was different: multiple sources of business transaction data — invoices, GST filings, bank feeds, inventory — that had to be reconciled into one coherent book of accounts without disrupting the SMBs using the product every day. The engineering pattern is the same one post-acquisition consolidation needs: a master-data layer, module-by-module migration, and strict preservation of statutory compliance throughout. We bring that pattern, the integration engineering to build the layer, and the discipline of releasing in increments that each pay for themselves.

What we do not do is quote a freeze. If a six-month cutover is what you want, there are larger SIs who will sell you one. If you want to retire the second stack without stopping the business, that is the work we take on. More on how we approach legacy modernization and transformation and on our India engineering practice.

The argument to take into the meeting

Three sentences, in this order:

1. The status quo is not free — here is the monthly burn across duplicate licences, reconciliation headcount, statutory exposure and unrealised synergies, and here is what it will accumulate to over the next twelve months of delay.
2. The big-bang cutover being quoted elsewhere has a one-in-six base rate of landing cleanly and would freeze operations for a quarter — we are not doing that.
3. We will fund Phase 0 from the budget already being spent on manual reconciliation, pick a Phase 1 module whose licence saving pays for its own migration within the year, and commit to each subsequent phase only after the prior one has banked the promised number.

That is the argument. The numbers behind it have to be your numbers, assembled from your actual licence contracts, your actual headcount and your actual deal thesis. Nobody else can build that paper for you — but once it is built, the decision usually makes itself.

Frequently Asked Questions

How long does post-acquisition system consolidation typically take for an Indian mid-market enterprise?

A phased strangler-fig consolidation is usually structured around modules, not a single cutover, with each major module taking roughly a quarter in a clean sequence. The total duration depends on how many modules and external integrations are in scope, how much historical data has to migrate, and whether the business is also redesigning processes at the same time. To move from a range to a realistic timeline, you need to scope the module inventory, the data cut-off decision, and the statutory calendar that constrains your cutover windows — that is the conversation to have with us or any serious partner.

What drives the cost of post-acquisition technology integration in India?

The five biggest drivers are, in order: the number and complexity of modules in scope (manufacturing and multi-location inventory are the hardest), the number of external integrations with banks, GSPs and partners, the volume and cleanliness of historical data to be migrated, the number of custom reports and workflows users genuinely need preserved, and whether process harmonisation is happening in the same programme. Phasing the work so each phase funds the next is the structural lever that most reduces the headline number a CFO sees.

Is a big-bang ERP cutover ever the right choice after an acquisition?

Occasionally — if both entities are small, the acquired entity has fewer than fifty users, there are almost no external integrations, and both businesses can genuinely absorb a two-to-three-day operational pause. Outside that envelope, the risk profile is poor: industry data shows the majority of large data migrations overrun their budget or timeline, and the failure modes include missed payroll and missed statutory filings. For most mid-market Indian acquirers, strangler-fig sequencing is the lower-risk path.

What is the audit risk of running two unreconciled sets of books after a merger?

Under Section 128 of the Companies Act 2013, failure to maintain proper books of accounts carries personal liability for the MD, CFO or whole-time director (Finance), with penalties including imprisonment up to one year or fines of ₹50,000–₹5,00,000. Non-reconciled dual books of a merged entity sit uncomfortably close to that standard, and GST filings based on mismatched masters compound the exposure. Your auditor and company secretary should assess your specific position — this is not legal advice — but the risk is real and grows with every closed quarter.

Can we start consolidating before the legal merger is complete?

The master-data layer and integration work almost always can — building a reconciled customer, vendor and item master, and exposing it to both ERPs, does not require the two legal entities to have merged. Transactional-module consolidation often has to wait for the scheme of arrangement to take effect, because the system of record for invoices and GL entries has statutory implications. Starting Phase 0 early is usually the single highest-leverage move an acquirer can make in the first six months after close.