The Weaker System Won: What a 12-Week M&A Integration Teaches About ERP Selection

Friday 18:00. 80 employees log out of their old ERP. Monday 08:00. The same 80 log into the new one.

The new one is objectively weaker.

Context: M&A integration. In 2025, an international corporation acquired an 80-person Mittelstand firm from professional services. Requirement: all systems and data into the corporate IT estate. Over a single weekend. No business interruption.

The corporate ERP could do less than the one it replaced. Different cost accounting, different reports, two incompatible data models. It still had to run.

This piece unpacks how that worked, why the statistical baseline predicted the opposite, and which lessons mid-sized IT leaders can take from an M&A integration into regular ERP selection. The topic sits inside my IT strategy and project management practice.

Why the Statistics Said No

The studies on M&A IT integration are blunt. Bain documents that 84 percent of all IT integrations following an acquisition experience significant issues. Gartner reports that 83 percent of all data migration projects miss budget or timeline. Panorama Consulting puts the 2025 discrete manufacturing ERP failure rate at 73 percent, with average cost overruns of 215 percent.

McKinsey adds the scale dimension: 30 to 50 percent of deal value is lost to slow or ineffective IT integration. Fewer than 20 percent of acquirers improve their IT costs and quality after a merger. For four out of five deals, the promised tech consolidation gain never materializes.

Against this backdrop, a fixed-price cut-over over a single weekend for an 80-person Mittelständler was a tall order. The standard Bain timeline for mid-market IT integrations is 12 to 18 months.

We had 12 weeks.

The Starting Position

The Mittelständler had grown organically over 14 years. The ERP setup was well adapted to professional services workflows, but only partially documented for the custom extensions. Two different cost accounting models coexisted, because an earlier subsidiary had brought its own logic. Reporting paths, approval hierarchies, and commission rules had grown deep into the system over the years.

The corporate ERP was designed for a different industry, a different scale, and a different reporting philosophy. It could do many things the Mittelständler did not need. It could do less of what the Mittelständler used daily. The mandate was not “select the best system.” It was “the corporate system wins, the data needs to fit.”

By McKinsey and Bain data, this is the normal case for M&A integrations. The acquirer’s system prevails, not the technically better one. What decides success or failure is process discipline.

The Approach: 12 Weeks Plus One Weekend

Weeks 1 to 4: Discovery

Reverse-engineering of the legacy systems. Every interface, every custom field, every manually maintained translation table got documented. This was the most time-consuming block. What would take two weeks against a documented software architecture took four against the grown Mittelstand environment.

Discovery is the phase most projects underestimate, according to McKinsey data. The risk: starting the mapping work without knowing what really happens at the source-system level. That is exactly what causes the 215 percent cost overruns Panorama measured for 2025.

Weeks 5 to 10: Mapping and Testing

Detailed field-level data mapping for every source-target pair. Multiple test runs in a stage environment. Every test run measured data integrity, surfaced mapping gaps, and identified edge cases in converting the two cost accounting models.

Three full dry runs before the real cut-over. Each dry run produced findings that triggered mapping corrections. By the third dry run, data integrity was at a level where the real cut-over became viable.

Weeks 11 to 12: Go-Live Prep

Runbooks for every step. Who presses which button at what time. Which validation runs afterward. Who gets notified. What is the rollback path if a validation fails. Training for the cut-over team. Communication plan for the 80 employees who would work with the new system on Monday morning.

A critical detail: the rollback path was planned even though we knew we could hardly execute it during the weekend. Just knowing it existed made the operational decisions during the cut-over weekend easier.

The Cut-Over Weekend

Friday 18:00. Last productive transaction in the old system. Logout of all users. Start of the automated data export.

Saturday and Sunday the conversion and validation scripts ran. Hour by hour we tested against the acceptance criteria defined during prep. At every validation step at least two project people were present.

Monday 08:00. Logins open. First productive transaction in the new system at 08:14.

The Results

Data integrity between source and target system: 99.3 percent. The missing 0.7 percent were deliberately taken out of scope because they covered historical records that were no longer relevant in the corporate context.

Finance reconciliation reduced from 3 days to 6 hours. 95 percent of reconciliation steps were automated after the cut-over. Before the project, the Mittelständler’s accounting team had needed three business days to verify the monthly close against the source systems. After the cut-over, six hours, because the mapping work in the discovery phase had created the foundation.

No critical errors. No rollback. No rework beyond planned fine-tuning. Fixed price held exactly.

The integration lead from the acquiring corporation wrote after go-live (anonymized):

“With other corporate combinations the go-lives were chaotic. With René’s planning everything ran like clockwork. We knew exactly what would happen, when it would happen, and what could go wrong. Nothing went wrong.”

ERP Implementation vs. M&A Cut-Over: Why the Approach Differs

Classical ERP selection and M&A IT integration get treated with the same project reflex in many mid-market companies. That is a frequent mistake. The two disciplines have different success criteria.

What Mid-Market IT Leaders Can Take Into Regular ERP Selection

Even without M&A pressure, the lessons transfer. Four points from this project that I now bring into every engagement.

Lesson 1: Process Beats System

The corporate ERP was objectively the weaker tool. Despite that, the cut-over went better than most classical ERP implementations that start with the theoretically perfect system and sink into the adoption swamp. The decisive factor is project discipline: discovery before mapping, mapping before testing, testing before go-live. Not the feature list.

For mid-market firms without M&A pressure this means: the question “which system has the most features?” is not the most important in the selection process. The more important question is “which approach matches our discipline?”. A simpler system with clean project execution beats a complex system with improvised rollout.

Lesson 2: Discovery Takes 30 Percent of Project Time, Not 5 Percent

In our case that was four out of twelve weeks, exactly 33 percent. In classical Mittelstand ERP implementations I often see discovery handled in two workshops, with the remaining time spent on configuration and customization. That is the root cause of the 215 percent cost overruns Panorama measures for 2025.

Concretely: anyone planning an ERP implementation over 12 months should budget 3 to 4 months for discovery. Reverse-engineering of current systems, documentation of informal workflows, surfacing of shadow IT in spreadsheets. That saves the almost-certain delays in months 7 to 10.

Lesson 3: Test Runs Are Not Optional

Three full test runs in our project. Each produced findings that required mapping corrections. Without these test runs the real cut-over would have become an improvisation weekend with unpredictable damage potential.

For classical ERP implementations the same discipline applies. At least one full end-to-end test with real source data in a production-like stage environment. Ideally two. Anyone who skips this because “we already do UAT” confuses acceptance testing with system testing. Both are needed.

Lesson 4: Runbook Beats Improvisation

The cut-over weekend ran quietly because every step was defined in advance. Who runs what action at what time, with what validation afterward, with what escalation path. Improvisation did not occur.

For classical ERP implementations the runbook principle is often underdeveloped. Go-live gets celebrated as “project completion” without a written hour-by-hour plan. Consequence: nobody knows whether the cash reconciliation runs Wednesday at 10:00 or only Friday at 16:00. That produces the friction that leads to issues in 73 percent of discrete manufacturing projects.

What the Case Does NOT Mean

Four clarifications, because the story invites simpler conclusions than it can carry.

First: it does not mean functional scope is irrelevant. For a regular ERP selection without M&A pressure, the fit of core functions to the business logic remains decisive. What the M&A story shows is the secondary role of feature depth versus process discipline, not its irrelevance.

Second: it does not mean every ERP is migration-ready in twelve weeks. Our case had 80 employees, a manageable data volume, and a clearly defined scope. Larger setups with multiple subsidiaries, international complexity, and regulatory data restrictions need the Bain standard timeline of 12 to 18 months or longer.

Third: it does not mean weaker systems should be preferred. When choice is free, that is outside M&A contexts, the better-fitting system wins. M&A integrations are a special case where choice is not free.

Fourth: it does not mean the same approach works without experienced support. The 12 weeks plus one weekend were possible because the project team handled the discovery work completely in four weeks. Anyone without that experience will need to plan a longer lead-up phase.

Frequently Asked Questions About M&A IT Integration

How does M&A IT integration differ from a regular ERP implementation?

In a regular ERP implementation, system selection is the central lever. In an M&A integration, it is pre-determined. The lever shifts to data mapping, cut-over choreography, and discipline in discovery. Success is not measured by adoption over months, but by data integrity on the cut-over date.

How long does an M&A IT integration project take?

For mid-market deals with clearly defined carve-out structures, 8 to 16 weeks plus a cut-over weekend is realistic, provided team experience is in place. Bain documents 12 to 18 months as standard for more complex deals. Cross-border deals and multi-entity structures often run 2 to 3 years.

What does an M&A ERP cut-over cost on a fixed price?

Fixed prices are possible in the mid-market with a clearly bounded scope. Prerequisite: a robust discovery phase with documented scope and a defined acceptance list. Without this upfront clarity, time-and-material billing is the more honest option. In our case the fixed price was possible because the carve-out scope was clearly defined by the acquiring corporation.

Who is liable for a failed cut-over?

Contractually the implementation partner for what was in scope. Operationally the acquiring management, because the operational consequences of a failed cut-over hit every business process. For this reason the role of the dedicated integration lead at the acquirer is the most important success factor per McKinsey data. 75 percent success rate with a named lead, 25 percent without.

What happens to the legacy systems after cut-over?

In our case the old systems remained available in read-only mode for three months for audit and research purposes, then were archived. The retention period depends on regulatory requirements. For German GmbH structures 10 years of retention is typical, which does not mean the live systems need to run that long. An archive snapshot is sufficient in most cases.

When is the right moment to start cut-over planning?

According to McKinsey: during due diligence, not after closing. Anyone starting IT integration planning after closing has already lost the first 100 days. In our case discovery started the day after signing, before operational closing.

How do I handle missing functions in the acquirer’s system that we need?

Three options, in this order. First: workaround in the acquirer’s system (often cheaper than expected when the workflow is rethought). Second: bilateral custom field with clear owner responsibility. Third: separate tool as a satellite. The workaround search is the rare case where less feature depth is better, when it simplifies the data cut-over.

Next Step

Do you have an M&A IT integration ahead of you, or a larger ERP migration on the horizon? I help mid-market IT leaders with the discovery phase, data mapping, runbook construction, and cut-over choreography, with a documented track record even under tight timelines.

→ Book a free initial consultation

→ Or read more first: IT Strategy and System Selection · Data Quality in the Mittelstand · Cash Management: Overambitious ERP Requirements · ERP Vendor Market 2026: 131 Criteria

Sources and further reading: Bain: M&A IT Integration Services · McKinsey: Understanding the Strategic Value of IT in M&A · Panorama Consulting: 2025 ERP Report · Godlan: ERP Implementation Failure Statistics 2025 · PMI Stack: 50+ Post-Merger Integration Statistics 2026 · Deloitte 2025 M&A Trends Survey