How Engineering Leaders Run Two Environments after an Acquisition without an Outage




How Engineering Leaders Run Two Environments after an Acquisition without an Outage
Why the overlap after a deal costs more than the plan says, what it looks like for each team, and how to keep both environments stable until one wins.
The deal has closed. The Monday after, you’re running two of everything, and the savings target is already in someone’s plan. The consolidation plan isn’t.
At a glance
A 2023 Deloitte analysis of 30 transactions found that “IT is the key driver for more than half the synergies obtained from the deal.” So most of the savings depend on technology, the technology takes years to converge, and the people who understand the acquired systems are among the most likely to leave in the meantime.
Sources: EY, citing EY-Parthenon research, 2024; Deloitte, 2023; MIT Sloan, 2019
So how do you keep both environments stable, and your team intact, while you decide what to keep, merge, or retire? Here’s what we’ve learned from running legacy and new platforms side by side while internal teams moved to what came next.
Why the overlap costs more than the plan says
Integration plans price the end state. The cost sits in the months between close and consolidation, for four reasons.

The duplicated environment doesn’t shrink while the decisions get made. It takes 10+ FTEs to run sustainable 24/7 coverage in-house once you factor in shift redundancy, PTO, sick days, and knowledge continuity. Two environments mean two rotations to hold at that level.

Merging access, cutting traffic over, and retiring a monitoring stack all touch systems your customers depend on. The gaps between the two stacks, where neither one is watching, are where outages come from.

The engineers who built the acquired environment know its quirks, and they’re among the people most likely to go. Once they do, every undocumented dependency is an incident waiting for a cause.

The deal model books the savings early, and the technology catches up in years, not quarters. That gap lands on you: hit the target while running both environments, with the same team that keeps production up.
The overlap looks different from every seat
One deal, three different workloads.
Infrastructure. Two monitoring stacks, two on-call rotations, and two sets of access to merge. Every consolidation wave needs a rollback plan, and the people writing it are the same people carrying the pager.
Data. Both data platforms keep running until one wins. Until then, the numbers come from two places, and nobody trusts a report until someone has reconciled it.
Platform. Two CI/CD pipelines and two Kubernetes environments, with developers from both companies shipping on whichever one they started on. Your platform engineers support both while they build the one everyone will move to.
What good looks like in the first year
None of this needs an outside partner to start. These five steps are the order we’d work in, and each one leaves something concrete you can hand to the next person.
- 01Map service ownership in the first 30 days. List every service with its owner, on-call, runbook, and a keep, merge, or retire call. You can’t plan a wave around a service nobody owns.
- 02Capture the acquired team’s knowledge before roles change. Have the people who run the systems today write the runbooks and access records. Once the reorg is announced, that window starts to close.
- 03Separate running the environments from changing them. If the same people do both, the run work wins every time and the consolidation slips. Give each its own owner and its own capacity.
- 04Set one standard for monitoring, on-call, and access early. Run both environments against it in parallel, so you’re comparing like with like before anything gets cut over.
- 05Consolidate in planned waves. Give every wave a rollback rule and a dated retirement. A platform with no retirement date is a platform you’ll run forever.
Where a dedicated run team fits
Step three is the one most teams can’t staff. Someone has to keep both environments stable while your engineers do the consolidation, and adding contractors you have to manage only moves the load onto your leads.
A dedicated team that owns the run work changes the math. It takes monitoring, incident response, and routine operations for one or both environments at a fixed cost, so the overlap has a known price and your engineers stay on the consolidation. We don’t bill hours; we own results.
We’ve run legacy and new platforms side by side before. For a global technology leader, we supported 10,000+ apps through a platform transition while its engineers built what came next. For a Fortune 100 technology company converging a legacy data stack with a new one, it was one month from onboarding to running operations under light supervision.
Apps supported through transition
Platform outages down 10x, holding above 99% uptime
Technical debt cut in half within 6 months
“Thanks to OpsWerks, we were able to accelerate our platform transformation and deliver results 24 months ahead of schedule. We’re incredibly grateful for their partnership throughout this journey.”
Due to strict enterprise confidentiality requirements, customer names and organizations are anonymized.
See how we ran a platform transformation for a global technology leader.
Read the case study- EY, “How CIOs can supercharge an M&A technology integration,” August 2024, citing EY-Parthenon research.
- Deloitte Switzerland, “Accelerating IT synergies capture, the key to achieve a successful M&A deal,” October 2023, an analysis of 30 transactions.
- MIT Sloan, “Your acquired hires are leaving. Here’s why,” January 2019, on Daniel Kim’s study of roughly 4,000 US high-tech startup acquisitions, 1990-2011.
- OpsWerks case studies: Accelerating Strategic Transformation for a Global Technology Leader; Resilient AI Data Platforms at Petabyte Scale.
Integrating an acquisition?
Bring the list of what’s running on both sides. We’ll walk through where the overlap risk sits and what a run team could take off your engineers first.
You define the outcomes. We own the delivery.
