Lesson 4 of 5
Handover to the run organization
8 min
At the end of hypercare, the project hands the solution to the people who will run it for years: the internal application support team, an application management partner, the SAP operations team under RISE, or a mix. A good handover is not a meeting at the end. It is a structured transition that starts weeks before exit and ends when the run organization can operate alone.
Who runs Contoso after hypercare
What the handover pack contains
| Item | Why the run organization needs it |
|---|---|
| Open tickets with history and workarounds | They inherit the backlog and must not re-investigate known issues |
| Known errors and workarounds list | Faster resolution of repeat issues |
| Solution documentation | Processes, configuration decisions, custom developments and interfaces in scope |
| Operations runbooks | Batch job schedule, interface monitoring, period-end tasks, restart procedures |
| Monitoring setup | Alerts, thresholds and recipients in SAP Cloud ALM, re-pointed to run teams |
| Test assets | Regression test cases, test plans and data needs, linked to solution processes |
| Contacts and contracts | Who to call at partners and SAP; service levels and escalation paths |
Contents of Contoso's handover pack.
Transition in stages
- Weeks 1–2ShadowRun team sits with hypercare experts and watches triage and fixes
- Weeks 3–4Reverse shadowRun team handles tickets; project experts watch and coach
- Week 5First line aloneRun team owns first and second line; project experts on call
- Week 6AcceptanceHandover pack reviewed; open items accepted; sign-off
Shadowing and reverse shadowing are where real knowledge moves. A document describing the billing interface is useful; watching an expert diagnose a failing message three times, then doing it yourself while they watch, is what makes the run team able to fix it at 06:00 on a Monday.
Operating model decisions to settle
- How changes are requested, prioritized and approved after go-live, and by whom.
- Release rhythm: how often transports move to production, and how SAP feature pack stacks and corrections fit in.
- Service levels for each priority and how they are reported.
- Who owns monitoring alerts and the response to them, by area.
- Who owns the regression test suite and runs it before each release.
- RequestBusiness raises a change or ticket
- PrioritizeProcess owner sets business priority
- Build and testRun team or partner builds; tests in quality system
- RegressionAffected processes regression tested
- Approve and releaseChange approved; transported in the release slot
Test the handover, do not assume it
Treat the handover like any other deliverable: define acceptance criteria and test them. During the week when the run team works first line alone, track how many tickets it resolves without escalating to project experts, how long resolution takes compared with hypercare, and which areas still need help. If the run team escalates every interface ticket, the interface has not been handed over, whatever the document says. At Contoso the acceptance criterion was simple: in the solo week, the application support team resolved at least 80 percent of tickets without project help, and every escalation had a knowledge transfer action.
Under RISE, also confirm the operational contacts on the SAP side: who receives service requests from the run team, how system operations such as backups and restores are requested, and how SAP Support incidents are raised and escalated. These contacts often sat with the technical lead of the project during the program and must move to the run team by name.
What would you do?
In week five, the application support team says it does not understand the custom interface to the carrier and does not want to accept it. The integration consultant leaves the project next week. What should Grace do?
- Handover is a staged transition: shadow, reverse shadow, first line alone, acceptance.
- The handover pack covers tickets, known errors, documentation, runbooks, monitoring, test assets and contacts.
- Settle the steady-state change path, release rhythm, service levels and test ownership before exit.
- Avoid the cliff edge: overlap teams and keep short on-call cover from key experts.
Check your understanding · not graded
Lesson check
1. What is reverse shadowing?
2. Why include test assets in the handover pack?
3. Which is a sign of a cliff-edge handover?
4. Under RISE, what helps define which technical operations SAP performs after go-live?