Post-Acquisition Data: The 180-Day Playbook
Your acquisition closed. Your ERPs, CRMs, and data warehouses do not match. A 180-day playbook for consolidating the estate without the multi-year integration.
The acquisition is signed. The press release is out. And somewhere in a conference room, a CFO is asking your data team when the synergy numbers will actually show up.
The honest answer most enterprises give is “eighteen to twenty-four months, after the integration project.” That’s also the wrong answer - not because it’s pessimistic, but because it treats data consolidation as one monolithic project. It isn’t. It’s a sequence of four phases, and the first two produce real business value inside the first thirty days if you run them correctly.
This post is the playbook we use on M&A data integration engagements - sequenced, with exit criteria per phase, and designed so reporting goes live long before the last legacy system retires.
The 18-month trap
The default integration pattern in most enterprises looks like this:
- Appoint a “data integration program”
- Procure a master data management (MDM) tool
- Spend 6 months designing the target architecture
- Spend 12 months building it
- Cut over on a weekend, discover twelve things you missed, spend another 6 months fixing them
During those 18-24 months, finance reconciles acquired-entity numbers in spreadsheets every close cycle. Sales operates two CRMs. The board asks about synergy realization every quarter and the data team says “after the integration is done.”
The problem isn’t the scope - it’s the sequencing. Identity resolution takes time. A consolidated EDW takes time. But Day-1 reporting does not. You can give finance a consolidated view of both entities within 30 days of close if you treat it as a reporting layer over the existing systems, not a prerequisite for the final target state.
Get the sequence right and your data team delivers four milestones the business can actually use:
| Day | Milestone | Audience |
|---|---|---|
| 1-30 | Consolidated read-only reporting | Finance, Exec team |
| 30-90 | Golden customer / product records | Sales, Marketing, Operations |
| 90-180 | Consolidated EDW, cutover schedule | Data teams, Finance |
| 180+ | Legacy systems retired on schedule | IT ops, CFO |
The rest of this post walks through each phase: what to do, who owns it, and the exit criteria to move to the next.
Phase 1 - Pre-close diligence (Day -30 to Day 0)
Most data integration plans fail because they start after the deal closes. By then the data estate is something you’ve inherited; the plan was built on whatever PowerPoint the banker produced during diligence. Neither of those is a reliable input.
Pre-close diligence changes the economics. Three things need to happen before the signing:
1. Source system inventory. Catalog every ERP, CRM, data warehouse, operational data store, file share, and BI tool at the target. Count licenses, count users, count data volumes. Most targets have 3x more systems than the LOI acknowledges - including shadow systems the CEO doesn’t know about.
2. Data quality snapshot. Run a same-day profile against the top 5-10 source tables that drive financial reporting. Count rows, null-rates, orphan keys, duplicate-customer rates. This number goes into the integration cost line item in the deal model. On one engagement, profiling revealed a 23% duplicate-customer rate in the target’s CRM - a detail that added $1.8M to the post-close integration budget and actually changed the closing price.
3. Integration cost estimate with a 6-month risk-adjusted plan. Based on (1) and (2), produce a phased integration plan that maps to the finance team’s synergy model. “Day 180” deliverables on the synergy slide should correspond to something concrete in the integration plan, not hope.
The diligence sprint runs 2-4 weeks and typically slots in alongside corp dev’s commercial diligence. It’s cheap insurance - the single biggest predictor of a clean integration is a CIO who walked in knowing what they were going to inherit.
Phase 2 - Day-1 connectivity (Day 1-30)
The moment the deal closes, acquired systems become readable. Not yet writable - just readable. This phase exists to deliver one thing: consolidated reporting that finance and the exec team can trust within 30 days, without touching production operational systems.
The pattern we use:
Read-only extraction into a shadow data lake. Point the Algoscale S.C.A.L.E. accelerator at every source system in the acquired entity’s estate - ERP, CRM, data warehouse, the spreadsheet a controller has been maintaining for two years. Full-load first, then nightly incrementals. Zero production writes, zero operational risk.
Side-by-side consolidated reports. The parent company’s existing reporting stack gains a new data zone - “AcquiredCo raw” - that mirrors the acquired entity’s reports. Finance can now see both entities’ close numbers in the same tool, on the same day. Not harmonized yet (different chart of accounts, different customer IDs) - but visible, refreshed nightly, and trustworthy enough to reconcile in a sitting, not a sprint.
Deferred decisions. Every identity-resolution question, every chart-of-accounts harmonization question, every “should this deal in acquired-CRM be the same account as this deal in parent-CRM” question - explicitly deferred to Phase 3. The temptation to start resolving identities during Day-1 connectivity is strong and wrong. It slows down the 30-day milestone without unlocking any real business value.
Exit criteria for Phase 2:
- Nightly extracts running for all critical source systems (success rate > 98%)
- Finance can produce a consolidated P&L by close Day 10 each month
- Sales leadership can see combined pipeline numbers in one dashboard
- Zero production writes from the consolidation pipeline
Done right, Phase 2 makes the CFO’s life measurably better inside 30 days of close. That’s the political capital you spend on Phase 3, which is harder.
Phase 3 - Identity and master data (Day 30-90)
The hard phase. Every customer, product, vendor, and employee exists in multiple systems with different IDs. Some of them should be the same record (the same Fortune 500 customer bought from both entities). Some of them shouldn’t. Resolving this is what makes consolidated analytics reliable and what every “Customer 360” project assumes is already done - which is why Customer 360 without MDM is cosplay.
This is also the phase where the business has to do work. IT can’t decide on its own which address, which email, which account manager wins when records conflict. Those are business decisions with real money attached.
The sequence we run:
Identity resolution across the Big Four entities.
- Customers - name + address + tax ID as the matching signal; manual review for the top 20% by revenue
- Products - SKU + description + manufacturer; often the hardest because of merchandising differences between banners
- Vendors - tax ID + DUNS where available; underrated source of synergy savings (consolidated purchasing unlocks negotiation leverage)
- Employees - payroll system is usually the source of truth; shadow systems (badges, laptops, SaaS tools) reconcile to it
Survivorship rules. When two records merge, which fields from which source win? Survivorship rules are business rules, not technical rules. They get set per entity type, written down, reviewed by finance and sales ops, and then applied programmatically. “Most recent wins” is a tempting default and almost always wrong - you want “most authoritative source wins,” where authority is defined per field. Address of record might come from the ERP; primary contact might come from the CRM; credit terms might come from a separate accounts-receivable system.
Chart of accounts harmonization. Finance-led. Not IT-led. IT can map accounts mechanically once finance decides the target structure. The mistake most enterprises make is letting IT design the chart of accounts because finance is too busy - it produces a chart nobody actually uses for reporting. The discipline: finance picks the target COA during Phase 3. IT loads it.
Pair this phase with an experienced data integration consulting partner if your data team hasn’t resolved identities across acquired entities before. The patterns are learnable but the first time through is expensive to learn in-house.
Exit criteria for Phase 3:
- Golden records exist for customers, products, vendors, employees
- Survivorship rules documented and applied
- Single chart of accounts in place (with a mapping table from each legacy COA for historical reporting)
- Finance has signed off on the COA as usable for the quarterly board deck
Phase 4 - Consolidated EDW and legacy sunset (Day 90-180)
By Day 90, the pieces are in place: consolidated reporting (Phase 2), golden records (Phase 3). Phase 4 is about making the consolidated environment the operational source of truth - not just a reporting layer on top of the legacy estate.
Build the target consolidated data warehouse using the Phase 3 golden records and the Phase 2 nightly extracts, now harmonized. If S.C.A.L.E. was used in Phase 2, the same infrastructure extends naturally - the extraction framework already exists; Phase 4 adds the transformation, conformance, and semantic layers that turn raw extracts into trusted facts and dimensions.
Define the cutover schedule. Not “the cutover” - the cutover schedule. Different legacy systems retire on different timelines depending on their dependencies:
- BI and reporting tools cut over first (they’re read-only consumers; safest to move)
- Operational CRM second (once the golden customer record is authoritative)
- Operational ERP last (general ledger is the hardest to migrate; GL migrations often slip to month 9 or 10)
Each system gets a sunset date, a migration owner, and an exit criteria. A system stays online past its sunset date if - and only if - it’s still being written to by an operational process that hasn’t migrated yet. Otherwise, freeze it and read-only-archive.
Parallel-run validation. During cutover, the legacy system and the new EDW run in parallel for one full close cycle. Same queries, side-by-side outputs, variance investigation on any row that doesn’t match. The parallel run is where last-minute issues surface - the kind that would otherwise show up in a board-level report three months later.
Exit criteria for Phase 4:
- Consolidated EDW in production, feeding all downstream reporting
- At least 2 legacy systems formally retired (usually the BI tools and one CRM)
- A dated sunset plan for the remaining legacy systems
- Board-level synergy reporting running out of the new EDW
What the numbers look like
Two engagements we’ve run recently, with anonymized metrics:
Mid-market manufacturing acquirer, $400M revenue. Target acquired with 3 ERPs (SAP, NetSuite, Oracle E-Business) and 2 CRMs. 180-day phased approach:
- Phase 2 delivered by Day 34
- Phase 3 completed by Day 96 (delayed by a chart-of-accounts disagreement between the two finance teams)
- Phase 4 partial completion at Day 180 - BI tools retired, Oracle E-Business scheduled for sunset at Day 270 due to a bespoke costing module
- Synergy reporting went live at Day 42; finance stopped reconciling in spreadsheets at Day 48
Financial services carve-out, divestiture side. Data had to be cleanly separated from the parent’s systems, handed to the buyer, then archived. Same four phases running in reverse:
- Pre-close: catalog of what belongs to the divested entity vs what stays with the parent
- Day 1-30: read-only extraction of the divested entity’s data into a handoff environment
- Day 30-90: identity resolution to isolate divested-entity customers and employees
- Day 90-180: handoff package to the buyer, parent-side retention cutover
Total elapsed time: 173 days. The buyer received a clean, documented data estate; the parent carved out with zero data-leakage incidents.
Common failure modes
After enough of these, the same three failures show up:
1. Starting with MDM before Day-1 reporting. Teams pick a shiny MDM tool, spend three months configuring it, and still haven’t delivered a consolidated P&L. Reverses the sequence. Day-1 reporting has to come first because it’s what funds the political capital for Phase 3.
2. Letting finance pick the chart of accounts in isolation. Or worse, letting IT pick it. The working chart of accounts needs joint finance + operations input. Otherwise either finance can’t close or operations can’t reconcile to the chart.
3. Underestimating the compliance audit scramble. Post-close, the acquired entity’s controls and audit trails need to slot into the parent’s compliance posture. HIPAA in healthcare, PCI-DSS in retail, SOX everywhere. If the data foundation enforces compliance at the infrastructure layer - encryption, access boundaries, audit logging - the audit scramble goes from a quarter-long project to a weekend review. If it doesn’t, every compliance review becomes a data-integration emergency.
Where to start
If you’re looking at an acquisition in the pipeline, or sitting on one that closed with no clear integration path: start with the Phase 1 diligence audit. The data estate review is small, quick, and produces the inputs the rest of the plan depends on. The full 180-day playbook, the accelerator that runs it, and the 45-minute walkthrough are all on our M&A data integration page.
The difference between 180 days and 18 months isn’t talent or budget. It’s sequencing.
Founder & CEO, Algoscale
Neeraj has led AI and data engagements for Fortune 500 clients across finance, healthcare, and retail. He writes about what actually ships — not what looks good in a slide.