The scenario and the assumptions
All figures are illustrative. Company A has about 300 engineers and 15,000 customers on its billing platform. Company B, now part of A, has about 120 engineers and 2,000 customers on a different billing platform. Each runs its own cloud accounts, CI system, identity provider and monitoring. The board expects synergies, but nobody has said what that means for engineering.
Start the post-merger integration case by asking what the deal was for. If the parent bought B for its product, B's stack may be the asset. If it bought B for its customers, the product may be retired over time. The integration plan follows from that answer, so say it out loud before drawing anything.
People first, because they hold the migration
A merger creates immediate uncertainty about roles, reporting lines and whose technology survives. Uncertainty is when good engineers take recruiter calls. The plan for the first thirty days is therefore mostly about people:
- Announce the combined engineering leadership within weeks, not months, even if the structure below it is still being designed.
- Identify the people who hold knowledge nobody else has, especially in B's systems, and agree retention arrangements with HR and finance.
- State what will not change for the first quarter: teams, managers, on-call and the products customers use.
Legal and HR set the boundaries here. Before the deal closes, competition rules may limit what the two companies can share or plan together, and legal will say what is allowed. After close, consultation duties, works councils and employment terms differ by country. You plan with them rather than around them.
Stack consolidation by layer, not by company
The common failure in stack consolidation is deciding that the acquirer's stack wins everywhere. That is politically simple and often wrong. Instead, publish criteria and apply them one layer at a time:
| Criterion | Question it answers |
|---|
| Migration cost | How many customers, how much data and how many services move in each direction? |
| Fitness | Which option already meets the combined scale, security and compliance needs? |
| People | Which team can run it, and will they stay to do so? |
| Contracts | What licence, renewal or exit terms apply to each vendor? |
| Strategic fit | Does the product the deal was for depend on this layer? |
Applied to the scenario, layers sort into three groups.
| Layer | Plan | Timing |
|---|
| Identity for staff, security monitoring | Converge early, because it is a risk control | First quarter |
| CI, observability, cloud account governance | Converge on one, chosen by criteria | Months 3 to 9 |
| Billing platform | Converge, direction decided by migration cost | Months 9 to 18 or later |
| B's core product | Keep separate until the product strategy is decided | Review at month 12 |
The billing direction shows why migration cost matters. Moving B's 2,000 customers onto A's platform, in waves of 200 a fortnight after a pilot, takes 10 waves, about 20 weeks. Moving A's 15,000 customers onto B's platform at the same pace takes 75 waves, about 150 weeks. Unless B's platform is far better, the direction chooses itself. The engineers who know B's billing system well become essential for those 20 weeks.
The architecture side of this decision is covered in what to do when two teams have built the same capability. This case adds the people and deal context a merger brings.
Why retiring a stack before securing its people fails
Sequencing stack consolidation ahead of retention is the mistake that sinks this plan. Announcing that B's billing platform will be retired tells B's billing engineers their expertise has an end date. If they leave in month three, nobody left understands the edge cases you must migrate, and the 20-week plan becomes a much longer and riskier one.
A strong plan reverses the order. Retention arrangements for named people come first. The decision to retire a system is announced together with what those engineers will own next. Their role in the migration is presented as important work, which it is.
Protecting customers during the migration
Customers did not choose the merger, and many will look for reasons to leave at renewal. The plan protects them in three ways.
First, no customer-facing changes in the first quarter. Second, each migration wave has a pilot group, success measures such as invoice accuracy and support contacts, and a stop condition that pauses the next wave. Third, customer-facing changes such as a new login or invoice format go through account teams early, and are not scheduled around a customer's renewal date.
For the mechanics of a cutover that cannot be fully undone, see choosing the cutover day and what rollback means. For a system that can never be switched off, replacing a system that cannot be switched off covers running both in parallel.
What the board sees each quarter
Report post-merger integration progress in terms the board recognises. Show regretted attrition in both legacy organisations, the number of duplicate systems retired, customers migrated with error and churn rates, and the running cost removed. Report the cost of the integration itself next to the savings, so nobody mistakes reduced licence spend for profit while two teams are still running two systems.
In post-merger integration, the technology plan is only as good as the people still there to carry it out. Secure them before you announce what gets retired.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).