Merging two codebases after an acquisition

Merging two codebases after an acquisition is a choice of shape followed by a sequence of small moves. The shape is chosen once, from four options, by looking at the two data models, the customer overlap and the two teams. The moves are then made one at a time, behind a stable interface, while both products keep serving customers.

That is the whole method. It fails in known ways: choosing the shape by politics, freezing both products for a rewrite that never lands, or adding engineers to a migration that is already late. This page sets out the decision, the sequence, and the three failure modes with the reason each one happens.

What are the four shapes of post merger software integration?

The four shapes differ in how much of each product survives and how much new code is written.

Shape	What happens	Best when	Cost profile
Absorb	One product's features are rebuilt inside the other; the absorbed product is retired	The acquired product is small, its customers can be migrated, and the acquirer's data model already covers its objects	Moderate, concentrated in migration and feature parity
Bridge	Both products keep running; a shared interface (single sign-on, shared customer record, shared billing) connects them	Customer overlap is low, the products serve different jobs, and the deal case is cross-selling rather than consolidation	Lowest up front, highest ongoing, since two products are maintained
Rebuild	Both products are replaced by a new platform, built to serve both customer bases	Both codebases are near end of life and the deal case depends on a product neither could become	Highest, longest, and the one most likely to fail
Federate	Products stay separate with a shared layer for identity, billing, reporting and data export; new features are built once in the shared layer	A buy-and-build platform expecting more acquisitions	Moderate up front, and it is the shape that scales to the fourth add-on

The names matter less than the rule for choosing. Look at the data model first: if the two products disagree about what a customer, an account or an order is, absorbing one into the other means resolving that disagreement, and bridging means living with it. Look at customer overlap second: high overlap favours absorb or rebuild, because customers should not see two products; low overlap favours bridge or federate. Look at the teams third, because whichever shape is chosen, the team that maintains the surviving system has to be the team that understands it.

Reveneau takes on post merger integrations as fixed-scope work in which the shared interface is specified first and an evaluation suite is written from that specification before any behaviour moves, so the fund can see each step pass rather than trust that the merge is going well. The pillar guide to technology after the deal sets integration among the four phases of post-deal work, and buy and build: consolidating acquired software platforms covers the federate shape when the fund plans to keep acquiring.

How do you move behaviour across without stopping either product?

You move behaviour across one piece at a time, behind an interface that does not change, until nothing is left on the old side. Martin Fowler describes this as the strangler fig application pattern: new capability is built on top of, yet separate from, the legacy codebase, and behaviour is moved from the old system into the new until the old system can be switched off.

Applied to a merge, the sequence is:

1. Put a stable interface in front of both products. Usually identity first (one login), then the customer record, then billing. Customers see one front door while two systems still run behind it.
2. Pick the smallest piece of behaviour with the fewest dependencies and move it to the surviving system. Verify it against the old system's outputs on real data before switching traffic.
3. Switch traffic for that piece, keep the old code for one cycle, then delete it. Deletion is the step teams skip, and skipped deletions are how a merge ends with three systems.
4. Repeat, in dependency order, so that each move only depends on moves already made.
5. Cut the last dependency and retire the old system, with a dated shutdown that the board sees in the quarterly report.

Each step is small enough to reverse. That is the property that lets both products keep running: at no point is the company betting a quarter's revenue on a migration landing.

Why does the team structure decide the outcome?

The team structure decides the outcome because systems copy the organisations that build them. Melvin Conway wrote in Datamation in April 1968 that organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations. Wikipedia's entry on Conway's law records a 2011 Harvard Business School and MIT study finding strong evidence for the same mirroring hypothesis.

For a merge, the consequence is direct. If the two engineering teams remain two teams, with two backlogs and two managers, the two systems will remain two systems whatever the integration plan says. If the target shape is absorb, the absorbed team joins the surviving team's backlog on day one. If the target shape is federate, one team owns the shared layer and the product teams consume it. The org chart is an architecture decision, and it has to be made in the same meeting.

The other structural rule is Brooks's law. Fred Brooks wrote in 1975 that adding manpower to a late software project makes it later, because new people need time to become productive and each added person adds communication paths. A late migration is where a fund most often reaches for more people, and it is where the law bites hardest. The scaling engineering teams guide covers the conditions under which adding people does help, and they are conditions a late merge rarely meets.

What does the fund see while the merge is running?

The fund sees a dependency count going down and four delivery measures holding steady. Those are the two signals that a merge is on track, and both can be reported without reading code.

The dependency count is the number of behaviours still served by the system being retired. It starts at the full list from step one of the sequence and falls to zero at shutdown. A quarter in which it did not fall is a quarter in which the merge stalled, and the report should say why.

The four delivery measures come from DORA, the DevOps Research and Assessment programme: change lead time, deployment frequency, change fail rate, and failed deployment recovery time. During a merge the fail rate and the recovery time are the ones to watch, because a merge that is being rushed shows up first as deployments that break. Reporting engineering progress to the fund gives the format, and the point of capturing the measures before the merge starts is that the board can then see whether the merge is degrading delivery of everything else.

Where do merges go wrong?

Merges go wrong in three places, and each has a cause that can be named in advance.

The shape is chosen by politics. The acquirer's team assumes its product survives; the acquired team, which may have the better codebase, is absorbed. The decision table above exists so the shape is chosen on the data model and the customers, and the decision is recorded in writing with the reasons, before either team is told.

Both products are frozen for a rewrite. The rebuild shape is the one most likely to fail, because it stops feature work on two products while a third is built, and the deal case usually needed the feature work. If rebuild is the right shape, it is still done as a strangler fig, one behaviour at a time, and never as a freeze.

Nobody deletes the old code. Every step in the sequence ends with a deletion, and deletion feels like risk with no reward. A merge that skips deletions produces a company with the acquirer's product, the acquired product, and a shared layer, all in production, all needing maintenance. Stripe's September 2018 survey of developers across six countries measured 17.3 hours of a 41.1 hour week going to maintenance; a merge that leaves three systems running has added to that number rather than taken from it.

What should exist before the merge starts?

Five things should exist before the first behaviour moves, and the operating partner can ask for each one:

• A written shape decision (absorb, bridge, rebuild or federate) with the data model, customer overlap and team reasons stated.
• A dependency list of every behaviour in the system being retired, which is the count the board watches.
• The stable interface specified, with an evaluation suite written from that specification.
• The team structure that matches the shape, effective from the start.
• The four delivery measures captured as a baseline for both products.

With those in place a merge is a sequence of small verified moves. Without them it is a rewrite with a deadline. If the fund would rather have the merge run by a team that takes the outcome, building with investors and their portfolio companies describes how we take on that work: the interface and its evaluation suite first, then the moves, each one shown passing.