Transition and Exit Planning for Managed Services
Every managed service is bought on the promise of a smooth start and sold on the assurance of a clean ending. Both are contract terms, and both are usually written last.
Transition and exit sit at opposite ends of a managed service and are the same problem: moving an operating responsibility between organisations without the service stopping. They are also the two phases with the least attention at contracting, because both parties are focused on the steady state in between.
The consequence is predictable. Transitions run late and the service degrades while nobody quite owns it. Exits become adversarial, because the incumbent has no incentive to make the handover easy and no obligation specific enough to enforce.
What a transition plan has to contain
- The knowledge to be transferred, itemised, with a named source on the client side or the incumbent side, and a date. Knowledge transfer described as a workshop series transfers very little.
- The access required, with lead times, requested at the start. Access is the most common cause of transition delay in every service.
- The parallel run: how long both parties operate, what is measured during it, and the criteria for ending it. Ending a parallel run because the date arrived, rather than because the criteria were met, is how services fail in the first month.
- The service levels that apply during transition, which are usually different from the steady-state levels and should be stated rather than implied.
- The acceptance criteria for transition completion, and who signs.
The transition risks that are actually different
Two risks in a transition have no counterpart elsewhere. The first is that the people who hold the knowledge are the people being displaced, so their cooperation cannot be assumed and should not be relied on without an arrangement that makes cooperation worth their while. The second is that the documented process and the actual process differ, often substantially, and the difference is invisible until the service is being run for real.
Both point to the same mitigation: observe the work being done before taking it over, rather than reading about it. A week of shadowing surfaces more than a month of document review, and it is the single most reliable predictor of whether a transition will hold.
Exit, which has to be designed at the start
An exit plan written at the point of exit is written by parties who have already fallen out. The exit provisions should therefore be agreed at contracting and maintained during the service, because the assets, the data formats and the dependencies all change while the service runs.
The provisions worth insisting on are specific. What data will be returned, in what format, and by when. What documentation exists and will be handed over, maintained to a standard rather than produced at the end. What assistance the incumbent will give, for how long, and at what price, because unpriced exit assistance is assistance that arrives slowly. What happens to third-party contracts and licences held on the client's behalf. And which staff, if any, transfer, which in many jurisdictions is a legal question rather than a commercial one.
Testing the exit before you need it
An exit provision nobody has tested is an assumption. The most valuable thing a client can do during a stable service is to exercise a part of the exit: request the data extract in the specified format, or ask for the current runbook, and see what arrives.
What usually arrives is instructive. Extracts turn out to be in a proprietary format, runbooks turn out to describe the service as designed rather than as operated, and the licence position turns out to be unclear. All of those are cheap to fix during a good relationship and expensive to fix during a bad one.
Maintaining the handover asset while the service runs
The practical way to make exit painless is to treat the handover material as a live asset rather than an end-of-life deliverable. The runbook is updated when the process changes. The knowledge register names the current owner of each area. The data model and its extract path are documented as they change.
This also serves the incumbent, and that argument is worth making internally. A service whose knowledge sits in three people's heads is a service that cannot absorb a resignation, cannot be priced accurately, and cannot be improved with confidence. Maintaining the handover asset is good operations before it is good contract compliance.