A blueprint for a ninety-day managed services transition when the outgoing team is leaving, the documentation does not exist, and the application cannot have a bad month.
This is a blueprint, not a client case study. The situation described is a composite of the conditions we design for, not a named engagement. Targets below are measures we would baseline and report against — not results already achieved.
A company is bringing an outsourced application portfolio to a new provider. Eleven applications, one of which processes the majority of the company's revenue. The incumbent's contract ends in ninety days and their team has already started leaving.
Documentation consists of an architecture diagram from 2019, a SharePoint folder of inconsistently maintained runbooks, and four years of ticket history in a system the incumbent owns.
The ticket history is the most valuable asset in the transition and nobody has treated it that way. It contains the actual failure modes, the real resolution steps, and the pattern of which applications break and why — all of it more reliable than any document.
The incumbent's contract end is fixed. Knowledge available in week one will not all be available in week ten as people leave.
A degraded transition on this application is a business event, not a service issue. It is sequenced first and staffed heaviest.
Cooperation varies. The transition plan cannot depend on goodwill, and has to extract what it can while people are still present.
Four years of failure-mode data needs exporting and mining before access ends.
There is no grace period. The service has to hit its targets from the first day of ownership.
The shape of the solution, before any of the detail below.
Ninety-day transition, then a service that improves
These are the calls that determine whether the engagement works — most of them made before any build starts.
Before shadowing, we export and analyse four years of tickets — volume by application, recurring incident patterns, actual resolution steps in the work notes, mean time to resolve by category, and who resolved what. This tells us which applications are fragile, what genuinely breaks, and which knowledge to prioritise extracting while the incumbent is still available. It is the single highest-value activity in the first fortnight.
The revenue application transitions first with the heaviest staffing. The remaining ten are sequenced by ticket volume and criticality, so the fragile ones get transition attention while incumbent knowledge is still accessible.
Three explicit stages per application. We observe the incumbent resolving live tickets; then we resolve with them observing; then we own with them available for escalation. Each stage has written exit criteria, so progression is a decision based on evidence rather than a date on a plan.
Every incident during shadowing produces a runbook entry or a known-error record. By the end of transition, the top ticket categories by volume have documented resolution procedures — written from live incidents, which makes them accurate in a way retrospective documentation never is.
The L1/L2/L3 split is derived from the ticket analysis, not from a generic template. Categories resolvable from a runbook go to L1; functional analysis to L2; code-level and vendor escalation to L3. The tiering is then validated against historical volume to size each tier properly.
Monitoring, alerting and synthetic transactions are in place before responsibility transfers, so day ninety-one is not the first time we find out how the application behaves under load.
Durations are indicative for an engagement of this shape. Yours would be sized during assessment.
Export and analyse the ticket history, inventory the estate, and build the transition plan around what the data shows rather than what the documents claim.
Activities
Observe the incumbent handling live incidents, prioritising the revenue application and the highest-volume categories.
Activities
Our engineers resolve live tickets with the incumbent observing and available, exposing knowledge gaps while they can still be filled.
Activities
Application-by-application transfer against written exit criteria, with the incumbent on call for escalation only.
Activities
Full ownership under SLA, with the first quarter focused on eliminating the recurring incidents inherited from before.
Activities
Every one of these is baselined before work starts, so the comparison at the end is defensible rather than flattering.
| Measure | Target | How it's measured |
|---|---|---|
| SLA attainment from day 91 | Meeting agreed targets in month oneResponse and resolution against severity targets, measured in shadow mode during transition so day 91 is not the first reading. | Response and resolution against severity targets, measured in shadow mode during transition so day 91 is not the first reading. |
| Runbook coverage of ticket volume | Top categories documented before transferProportion of historical ticket volume covered by a runbook or known-error entry, tracked as a transition exit criterion. | Proportion of historical ticket volume covered by a runbook or known-error entry, tracked as a transition exit criterion. |
| First-contact resolution at L1 | Baselined month one, improving quarterlyTickets closed at L1 without escalation — the clearest signal of whether knowledge capture actually worked. | Tickets closed at L1 without escalation — the clearest signal of whether knowledge capture actually worked. |
| Escalations to the incumbent after transfer | Declining to zero within the standby windowCount of escalations per application per week during the standby period. | Count of escalations per application per week during the standby period. |
| Ticket volume trend by root cause | Top three inherited causes eliminatedVolume by cause tracked monthly, so the service demonstrably improves rather than steadily servicing the same faults. | Volume by cause tracked monthly, so the service demonstrably improves rather than steadily servicing the same faults. |
Named up front. A risk register written after something goes wrong is just a post-mortem.
Ticket mining happens first and does not depend on people. Shadowing is front-loaded onto the highest-risk applications, and sessions are recorded.
Full export is taken in the first fortnight as a contractual transition requirement, before any dependency on continued access builds.
Dependency mapping during discovery plus reverse-shadowing on live incidents exposes most of them while the incumbent is still reachable.
It transitions first, with the heaviest staffing, the longest reverse-shadowing window and explicit exit criteria before ownership moves.
It never does. Tell us where yours differs and we'll tell you honestly whether we're the right people for it.
Or email us directly at reachus@segakiv.com