The short version
- Every acquisition adds a monitoring stack, and the plan to consolidate it gets descoped in the second quarter. This is not a failure of execution; it happens almost every time, for reasons that are structural.
- The integration cost nobody budgets is the on-call rota. Two estates means two sets of alerts, two sets of tribal knowledge and, in practice, two rotas that cannot cover for each other.
- A normalisation layer decouples absorption from migration. One incident shape, one runbook library, one rota — while the acquired tooling stays exactly where it is for as long as it needs to.
- The measure is time-to-one-rota, not time-to-decommission. The second may never arrive. The first can be weeks.
The integration plan always has a tooling workstream. It is always scheduled for the second or third quarter after close. It is almost always the thing that gets descoped when the revenue synergies turn out to need more attention than expected.
Two years later the acquired platform is still on its original monitoring stack, still has its own on-call rota, and the two organisations still cannot cover for each other at 3am. Everyone involved knows this is suboptimal. Nobody can find the quarter to fix it.
Why the consolidation does not finish
It is worth being precise about the failure mode, because the usual diagnosis — not enough focus — leads to the wrong remedy.
The last twenty per cent is the expensive part. Dashboards migrate easily because they are declarative and visual: you can tell at a glance whether the new one matches. Alert rules do not. Each one encodes a hard-won lesson about a specific failure mode, often with a threshold someone tuned after an outage. Migrating it means understanding why it exists, and the person who knows is frequently no longer at the company.
The acquired team is correct to resist. Their alerting works. It catches the things that break in their estate. Asking them to move to a stack that does not yet have those rules is asking them to accept a period of being blind, during exactly the period when everyone is watching whether the acquisition is going well.
The benefit arrives only at the end. Running two stacks at eighty per cent migrated is strictly worse than running two stacks at zero per cent: you now have the cost of both plus the confusion of split ownership. The payoff is entirely at decommission, which is the part that never happens.
The cost that is not on the integration spreadsheet
Licences are visible and get counted. What does not get counted is that you now have two on-call rotas that cannot substitute for each other, two bodies of tribal knowledge, and an engineer population where nobody can competently hold the pager for the whole business. That is the expensive part, and it compounds with every further acquisition.
Separating absorption from migration
The insight that unlocks this is that absorbing an estate and migrating its tooling are two different projects, and only one of them is urgent.
What the business actually needs is one rota, one view of what is broken, and one set of people who can respond. What it does not need — at least not this year — is for the acquired team's Datadog to become your Prometheus.
incident shape"] NR --> N PD2 --> N P --> N CW --> N PD1 --> N N --> RB["One runbook library"] RB --> R(["One rota, one console,
one set of evidence"]) style N fill:#f4f6ff,stroke:#a78bfa,stroke-width:2px style R fill:#e8f8f4,stroke:#22c1a4,stroke-width:2px
Nothing in the acquired estate changes. Their alerts keep firing from their tools, tuned the way their team tuned them. What changes is that those alerts now arrive somewhere your people can see, in the same shape as everything else, matched against a runbook library that both teams contribute to.
And crucially: this is reversible and incremental. You can point one alert source at it in an afternoon. If it does not help, you have lost an afternoon rather than a quarter.
What the first ninety days look like
| Week | What happens | What it buys |
|---|---|---|
| 1–2 | Point the acquired estate's paging tool at the webhook, read-only. Nothing else changes. | Their incidents are visible to your team, with labels and severity normalised. |
| 3–6 | Their most-fired five alerts get runbooks written by their engineers, in the same format as yours. | Their tribal knowledge starts leaving individual heads. Your engineers can read it. |
| 7–10 | The agent runs those runbooks read-only. Compare its evidence against what their on-call actually did. | Confidence, measured on their estate rather than asserted from yours. |
| 11–13 | One rota covers both estates for the alert classes with runbooks. The rest still routes to their team. | The integration benefit, without the migration. |
Note what is absent: no tool is decommissioned, no team is asked to abandon alerting they trust, and no quarter is booked against a migration. The acquired estate's tooling can be retired in year three, or never, and the rota benefit does not wait on that decision.
Where this does not help
Licence consolidation. If the business case for the acquisition promised tooling savings, this approach does not deliver them — you are still paying for both stacks. It delivers the operational benefit that the licence saving was really a proxy for. Be straight about that distinction when the synergy tracker comes round, because the alternative is being asked later why the decommission slipped again.
The metric to adopt
Most integration programmes measure time to decommission. It is the wrong number: it is long, it slips, and it measures something the business does not directly feel.
Measure time to one rota instead — the point at which an engineer from either side can hold the pager for the combined estate and be effective. That is the thing the business actually wanted, it is reachable in weeks rather than years, and it does not depend on a migration completing.
For organisations that acquire regularly, this compounds into something more valuable than any single integration: a repeatable absorption process. The fourth acquisition takes days rather than quarters, because the layer that normalises alerts and holds runbooks already exists and the only new work is writing the runbooks.
Three ways to read this
If you own the integration
Split the workstream in two on the plan: absorb (weeks, high value, low risk) and migrate (quarters, contingent, deferrable). Report on the first. The second stops being a broken promise the moment it stops being the only path to the benefit.
If you acquire regularly, the absorption layer is infrastructure, not a project.
If you run the support org
Get the acquired team writing runbooks in your format before anyone asks them to change tools. It is a far easier conversation, and it is where their knowledge actually transfers.
Time-to-one-rota is a number you can own and report. Time-to-decommission is not.
If you will implement it
Check the normalisation carefully on the acquired estate's payloads specifically. Vendors vary their webhook shapes, and the resolve events are usually thinner than the create events — if dedupe matches only on a fingerprint built from labels, their closes will be silently dropped and incidents will stay open for ever.
Ask for read-only credentials on their side first. It is the fastest thing to get approved during an integration, when everything else is contested.
Next
That completes the operating-model series. The next one is about how the product implements it, starting with the whole loop — receive, match, execute, resolve, learn.