Service Transition
Service transition is the set of activities that move a system from the project that built it to the organisation that will run it. It covers the support model, service levels, operational documentation, monitoring, access, licences, knowledge transfer and formal acceptance. It is normally planned alongside the go-live rather than after it, and closes with a recorded handover.
A project delivers a system; an organisation runs a service. Service transition is the work of turning the first into the second, and it is scheduled work with its own owner rather than a conversation held in the last week. The receiving organisation has acceptance criteria, and those criteria are agreed early enough to influence what is built.
What it contains
| Element | What is transferred or agreed |
|---|---|
| Support model | Who takes first, second and third line; hours of cover; the escalation path and on-call arrangements |
| Service levels | Response and resolution expectations by priority, and how they are measured and reported |
| Operational documentation | Runbooks for routine tasks, batch schedules, recovery procedures, architecture and interface descriptions |
| Monitoring and alerting | What is monitored, what thresholds raise an alert, and who receives it |
| Access and accounts | Administrative accounts, service accounts, privileged access and the process for granting it |
| Knowledge transfer | Sessions delivered to the support team, with a record of who attended and what was covered |
| Known issues | Open defects, workarounds and planned fixes, transferred as a list rather than as folklore |
| Contracts and licences | Vendor support agreements, licence counts, renewal dates and who now owns them |
| Cost and ownership | Which budget carries the run cost, and who the named service owner is |
| Acceptance | The criteria the receiving organisation applies, and the recorded sign-off against them |
The Project Closure Report (Excel) holds the handover checklist alongside the closure record, since a project cannot be closed until the service has been accepted by someone.
How it is used
Transition activities are planned backwards from go-live: knowledge transfer before the support team is expected to answer questions, monitoring in place before the system carries live traffic, access granted before anyone needs it at three in the morning. Where hypercare or early life support is used, transition is not complete until that period ends and the delivery team steps away.
The acceptance step is what gives it a definite end. Without a signed acceptance, ownership stays ambiguous and the project team is called back indefinitely. The project closure guide covers how handover, benefits ownership and lessons learned fit together at the end of a delivery.
Where it goes wrong
Late engagement is the most common failure: the support organisation is shown the system a fortnight before go-live and asked to accept it. By then the things they would have asked for — logging, monitoring hooks, a supportable configuration — are expensive to add.
The second is documentation written to satisfy a checklist rather than to be used, which is discovered the first time someone has to recover a failed batch. The third is unfunded run cost, where nobody agreed which budget pays for the licences and the support hours. The fourth is transition declared complete while a hypercare rota is still running, so the handover is nominal.
The fifth is knowledge transfer delivered as a presentation. Sessions that walk a support team through slides produce attendance records and very little capability; sessions where support handles real tickets with the delivery team beside them produce the opposite. The distinction matters most for the routine operational tasks — batch failures, reprocessing, access requests — which are what the support team will actually spend its time on.
Related terms
See also early life support, hypercare and go-live.
Questions
When does service transition start?
In planning, not at go-live. The receiving organisation's acceptance criteria are most useful when they are known early enough to influence design, documentation and monitoring.
What is handed over in a service transition?
The support model and service levels, operational documentation, monitoring, access, known issues, licences and contracts, plus a record of the knowledge transfer delivered.
Who accepts the service?
The named service owner in the organisation that will run it, against criteria agreed in advance and recorded as a sign-off.
How does service transition relate to project closure?
Closure normally depends on it. A project with no accepted service owner cannot transfer responsibility, and the delivery team stays engaged by default.