You've just closed on your fifth acquisition. The deal team is celebrating, but you're staring at a spreadsheet showing four different CRMs, three accounting packages, and an acquired company still running email through a closet server from 2014.
That gap between signing the deal and actually seeing the promised efficiencies? That's IT PMI — the technical integration work that determines whether your roll-up runs like one company or a loose collection of businesses sharing a logo.
Here's what the evidence consistently shows: the technical work is rarely the hard part. It's the sequencing, the people, and the discipline to keep the business running while the systems change underneath it. Between 70% and 90% of M&A deals fail to deliver expected value, and the reasons are almost always execution, not strategy.
This guide covers the practical reality of post-acquisition system migration — what to do, in what order, and how to avoid the mistakes that derail most integration projects.
Why System Migration Fails After Acquisition
Most post-acquisition system migrations don't fail because of technical problems. They fail because of timing, sequencing, and underestimating the human element.
Three patterns show up repeatedly:
- Rip and Replace Disaster — forcing acquired teams onto platform systems in week one, before understanding their workflows. Result: rebellion, workarounds, and your best acquired talent updating their LinkedIn profiles.
- "We'll Get to It Later" Drift — postponing integration until you've got eight companies on different systems, inconsistent data, and no single source of truth for board reporting.
- One Size Fits All — applying the same 90-day playbook to a 3-person tuck-in and a 200-person strategic acquisition.
Each pattern shares a root cause: treating IT PMI as a technical checkbox rather than an operational transformation.
The Hidden Costs of Delay
The brutal reality? Every month you delay integration, you're paying for it — you just can't see the invoice.
Those hidden costs compound:
- Duplicate software licences — it's common to find £30-50k in annual savings just from consolidating subscriptions across 5-10 acquisitions
- Manual reporting workarounds — your finance team spending 20+ hours monthly reconciling numbers from disconnected systems
- Security exposure — that closet server with customer data and no backup policy
- Decision delays — can't see consolidated pipeline or capacity across the group because data lives in silos
Picture a PE-backed facilities management roll-up that delayed integration across seven acquisitions. By the time anyone looked at the estate, they were paying for 14 separate accounting systems. Not because anyone chose that — because nobody chose otherwise.
The math is straightforward: the longer you wait, the more expensive and complex the eventual migration becomes. According to Valorem Reply, slow IT integration can erode 30-50% of deal value. Integration debt compounds just like technical debt.
Planning Your IT PMI Migration Strategy
Before you touch any systems, you need a clear picture of what you're working with. Skipping the discovery and audit phase is the fastest route to a failed migration.
Discovery and System Assessment
Start with a complete system inventory. Not what's on the IT asset register — what people actually use.
This means:
- Software audit — every application, who uses it, what data it holds, who administers it
- Department head interviews — understand actual workflows, not documented processes
- Data quality assessment — what shape is the data in? (Spoiler: worse than you think)
- Shadow IT discovery — the spreadsheets, personal Dropbox accounts, and yes, the closet servers
Pro Tip: Walk the building. Physically. You'll find systems nobody mentioned because "it's just how we've always done it." We call this the Closet Server Test in our integration playbook — and it catches shadow IT that no software audit will surface.
Once you understand what exists, you can decide how deeply to integrate. Not every acquisition needs full consolidation — a concept we call Minimum Viable Integration. Here's the three-tier framework:
| Integration Level |
What It Means |
Best For |
Timeline |
| High-Touch |
Full system consolidation — single ERP, single CRM, unified processes |
Operationally similar acquisitions where standardisation drives clear value |
3-6 months |
| Medium-Touch |
Key systems unified, some operational independence |
Acquisitions needing visibility without full control |
6-12 weeks |
| Low-Touch |
Connect only what's needed for financial reporting and security |
Acquisitions where independence is part of the value |
2-4 weeks |
Prioritising What to Migrate First
Sequencing matters more than most people expect. Get it wrong and you'll create more problems than you solve.
The recommended migration order:
- Email and Communication — security baseline, quick win, visible to everyone
- File Storage — often bundled with email migration (Google Workspace or Microsoft 365)
- Finance/Accounting — CFO visibility, board reporting
- CRM — sales pipeline visibility across the group
- HR/Payroll — compliance and people management
- ERP/Operational Systems — deepest integration, last to move
Why this order? Email is low-risk, high-visibility. It shows the acquired team that change is coming and it's manageable. Finance comes next because your PE sponsors want consolidated numbers. CRM follows because pipeline visibility drives growth decisions.
ERP and operational systems come last because they're the most complex and disruptive. By the time you get there, you've built trust with the acquired team and learned their workflows. We cover each system type in more detail in our system migration essentials guide.
Warning: Don't migrate CRM before you've cleaned the data. Gartner reports that 83% of data migrations fail or exceed budget — and dirty source data is usually why. Budget time for data cleanup. It always takes longer than expected.
Executing the Migration Without Disrupting Operations
The principle that should guide every migration: the business keeps running while the systems change.
This requires more deliberate planning than most teams expect. Here's how to structure the first 100 days of execution:
Pre-Migration (1-2 weeks)
- Data cleanup and preparation in the source system
- Test migrations in a parallel environment — never test in production
- User communication: what's changing, when, and why
- Optional pre-migration training for affected staff
Migration Weekend
- Production migration with documented rollback plans
- System configuration and integration testing
- Validation that data arrived intact and complete
Post-Migration (1-2 weeks)
- User acceptance testing with actual users doing actual work
- Issue tracking and rapid fixes
- Parallel running where feasible (old and new systems simultaneously)
Key Insight: Schedule migrations for low-activity periods. For most B2B service businesses, that's a weekend. For others, it might be the first week of a new month after close. Ask the acquired team — they know their busy periods.
Documentation matters more than most people realise. Every migration should produce:
- System architecture diagrams
- Data maps showing what moved where
- Admin guides for ongoing management
- Known issues and workarounds
This documentation becomes critical when you're doing your tenth acquisition and need to repeat the process. Without it, you're starting from scratch every time.
Managing People Through System Change
You can migrate systems faster than you can change behaviour. That single fact explains more failed integrations than any technical issue.
People don't adopt new systems when they feel things are being done TO them rather than WITH them. According to EY, 47% of employees at acquired companies leave within the first year — 3.6 times the normal turnover rate. Poorly handled system changes accelerate that. We cover the full training and adoption framework here, but three principles matter most:
1. Explain the Why Before the What
Acquired employees are already anxious. New owners, new boss, uncertainty about their future. Forcing system changes without context confirms their worst fears.
Before any migration, communicate:
- Why the change is happening (not "efficiency" — the real business reason)
- What's changing for them specifically
- What's NOT changing
- Who to ask if they have questions
2. Train Before Go-Live, Not After
A Train-the-Trainer model works best here. Identify 2-3 people in the acquired company who are respected by their peers and reasonably tech-comfortable. Train them first. They become your Digital Champions — peer influencers who answer questions and model the new behaviours.
This works better than external trainers because champions understand the local context and speak the team's language.
3. Make Early Wins Visible
Nothing builds buy-in like demonstrated benefit. After email migration, show the team their new shared calendar working. After CRM migration, show a sales manager their consolidated pipeline view.
Real Talk: Some resistance is actually feedback in disguise. If three people in accounts are telling you the new ERP doesn't handle their commission structure, listen before you push. Sometimes the system genuinely doesn't fit the workflow — and forcing it creates workarounds that are worse than what you replaced. The goal isn't compliance, it's adoption.
Post-Migration Stabilisation and Hypercare
Go-live is the beginning, not the end.
The two weeks after migration — what we call the hypercare period — determine whether adoption sticks or systems get abandoned for "the old way."
Hypercare means:
- Dedicated support availability — someone to answer questions immediately, not a helpdesk ticket that takes 48 hours
- Daily check-ins with department heads to surface issues early
- Rapid fixes for anything blocking work
- Tracking adoption metrics — are people actually using the new systems?
Common post-migration issues:
- Users reverting to spreadsheets because the new system "doesn't work how they need it"
- Data quality problems that weren't caught in testing
- Integration gaps between migrated systems and tools that weren't in scope
- Permission and access issues preventing people from doing their jobs
Most of these are fixable quickly IF you catch them in the first week. Left for a month, they become entrenched workarounds.
Pro Tip: Schedule a formal 30-day review. By then, the dust has settled and you can assess what's working, what needs adjustment, and what lessons apply to your next acquisition.
Document everything that went wrong and why. This becomes your playbook for the next deal. Roll-ups that treat each integration as a learning opportunity compound their capabilities. Those that don't keep making the same mistakes.
The Bottom Line
Post-acquisition system migration isn't a technical project — it's an operational transformation that happens to involve technology.
Get it right, and you turn five companies into one platform with consolidated visibility, reduced costs, and the operational efficiency your deal thesis promised. Get it wrong, and you're managing a portfolio of disconnected businesses while paying for the overhead of centralisation.
Key Takeaways:
- Match integration depth to strategic intent — not every acquisition needs full consolidation
- Sequence migrations deliberately: email first, ERP last
- Budget time for data cleanup — it always takes longer than you expect
- Invest in people change as much as technical change
- Hypercare in the first two weeks determines long-term adoption
Your Next Steps:
- Audit your current estate — how many systems are you actually running? (Our integration audit checklist can help)
- Classify each acquisition: High, Medium, or Low-Touch integration
- Decide who's doing the work — internal team, contractors, or a specialist partner
- Identify your Digital Champions in each acquired company
We cover IT PMI in more detail in our Roll-Up Integration Playbook — grab a free copy if you want the full framework, checklists, and templates.
If you're mid-acquisition and staring at a messy system landscape, we're happy to talk through your situation. No pitch, no pressure — just a second opinion from people who focus on this every day. Book a discovery call when you're ready.
Frequently Asked Questions
What is post-acquisition system migration and why does it matter?
It's the process of getting the IT systems of your newly acquired company working with (or replaced by) your platform systems. Until you do it, you're running separate businesses that happen to share an owner — you can't see consolidated numbers, you're paying for duplicate tools, and your board is asking why the "synergies" haven't shown up yet.
What should you migrate first after an acquisition?
Start with email and file storage — it's low-risk, high-visibility, and gets security sorted. Then finance and accounting so your CFO can actually see consolidated numbers. CRM comes next for pipeline visibility. Leave ERP and operational systems until last — they're the most complex and disruptive, and by then you've built trust with the acquired team.
What are the hidden costs of delaying IT integration?
The ones that hurt most are the ones you can't see on an invoice: duplicate software licences (often £30-50k annually across 5-10 acquisitions), your finance team spending 20+ hours a month manually reconciling numbers, security risks from unpatched legacy systems, and delayed decisions because your data lives in silos. These compound every month you wait.
How long does a post-acquisition system migration take?
It depends on how deeply you need to integrate. Low-touch (financial reporting and security basics): 2-4 weeks. Medium-touch (key systems unified, some operational independence): 6-12 weeks. High-touch full consolidation (single ERP, single CRM, unified processes): 3-6 months. The right answer depends on what value you're trying to capture from each acquisition.
What is the hypercare period?
The two weeks immediately after go-live where you have dedicated support available, daily check-ins with department heads, and rapid fixes for anything blocking work. This is where adoption either sticks or falls apart. Skip it, and people revert to their old spreadsheets within a month.
How do you stop acquired employees from resisting new systems?
You don't "stop" resistance — you reduce it by being respectful about the change. Explain WHY before WHAT. Train people before go-live, not after. Identify respected team members who can act as Digital Champions and support their peers. Make early wins visible. And when someone tells you the new system doesn't work for their workflow, listen — sometimes they're right.
