A managed services transition has a fixed deadline, an outgoing team with limited incentive to help, and documentation that is almost always worse than advertised. Ninety days is the usual window and it is not generous.
Most transition plans are built around shadowing. Shadowing matters, but it depends entirely on the outgoing team still being present and willing — and by week six, often neither holds.
Start with the ticket history
The single most valuable asset in any transition is the incumbent's ticket history, and it is routinely treated as an archive rather than as the primary source it is.
Several years of tickets contain what genuinely breaks, how it was actually resolved, which applications are fragile, and how long things really take. It is more reliable than any document, because it was written by people solving real problems rather than by someone completing a documentation task.
Export it in the first fortnight and mine it for:
- Volume by application and by category — where the work actually is
- Recurring incidents — the same fault appearing monthly is a fix, not a ticket
- Resolution steps in the work notes — draft runbooks, already written
- Time to resolve by category — realistic SLA sizing rather than aspirational
- Who resolved what — which knowledge to prioritise extracting, and from whom
Sequence by criticality and fragility
Transitioning applications in whatever order the incumbent finds convenient is common and wrong. Sequence by business criticality first, then by fragility as the ticket data shows it.
The application carrying the most business risk transitions first, with the heaviest staffing and the longest reverse-shadowing window. This is counter-intuitive — there is a pull towards starting with something easy — but transition quality degrades as the incumbent's team thins out, and you want your best access spent on your biggest risk.
Three stages, with written exit criteria
Shadow, reverse-shadow, own. The stages are standard; what separates a good transition from a nominal one is that each has exit criteria written down in advance.
- 1Shadowing — we observe the incumbent resolving live tickets. Exit: runbook drafts exist for the top categories by volume.
- 2Reverse shadowing — we resolve with them observing. Exit: a defined run of tickets resolved without intervention, and identified gaps closed.
- 3Ownership — we own, they are on escalation standby. Exit: escalations to the incumbent reach zero.
Without written criteria, stage progression becomes a date on a plan rather than a judgement about readiness, and the plan will always say you are ready.
Build the runbooks from live incidents
Documentation written retrospectively describes what someone believes the process to be. Documentation written during a live incident describes what actually happened, including the step that is not in any diagram.
Every incident handled during shadowing and reverse-shadowing should produce either a runbook entry or a known-error record. By day ninety the top ticket categories by volume have procedures that have been used rather than reviewed.
Instrument before you own
Monitoring, alerting and synthetic transactions need to be in place before responsibility transfers. Day ninety-one should not be the first time you observe how the application behaves under real load.
Running SLA measurement in shadow mode during the final stage is worth the effort too. It tells you whether the targets you agreed are achievable while the incumbent is still available to explain why something takes as long as it does.
What good looks like at day ninety-one
- Runbooks covering the majority of historical ticket volume
- A populated known-error database, built from real incidents
- Monitoring and alerting live, tuned on observed behaviour
- SLA measurement already proven in shadow mode
- Escalations to the incumbent already trending to zero
- A root-cause backlog of the recurring faults you have inherited
That last one matters more than it looks. A transition that ends with a plan to eliminate inherited problems is a service that gets better. One that ends with a plan to service them is a service that stays exactly as expensive as the one it replaced.