The month-two collapse
Go-live gets the war room, the executive attention, and the applause. The support model’s real test comes later and quieter: hypercare ends, the consultants roll off, the AMS contract starts — and somewhere in month two the cracks show. The person who understood the custom interface is gone. The triage model was never actually agreed, so every ticket is a negotiation. The SLA tiers, copied from a template, do not match the ticket mix the business actually generates. None of this is bad luck. It is the predictable result of treating the hypercare exit as a calendar event instead of a designed handover.
SAP’s own methodology quietly makes the point. SAP Activate frames the post-go-live transition as contractual and planned: the team stays on for “a predetermined period of time, which is usually defined in the contract or agreed as part of the plan to transition to operations”. A predetermined period, defined in a contract, as part of a plan — three phrases describing a design artifact. Most programs under-specify exactly this.
What SAP actually defines — and the one number it publishes
The phase boundaries first. In SAP Activate, the Deploy phase sets up the production environment and confirms readiness to switch into business operations, and the team “performs sustainment and hypercare activities in the Deploy phase once the system goes live”; Run is the support and management of the productive solution post-go-live, spanning incident and change management, system and application monitoring, and upgrade management. Hypercare itself is characterized as short-term intensive support with rapid issue resolution, in which the new system is further stabilized and optimized.
How long is hypercare? Here honesty requires precision, because this is where invented benchmarks flourish. SAP publishes exactly one attributable duration figure in this territory: its packaged Enhanced Operations Service for Hypercare Phase has a fixed service duration of four weeks, with a three-week planning lead time. That is the duration of one specific SAP service — a useful reference point, but not a universal hypercare length. There is no industry-standard hypercare duration; SAP Activate says only that the period is predetermined and agreed. Anyone who tells you “hypercare is always N weeks” is quoting folklore. The right duration is whatever your stability evidence and your contract say it is — which is precisely why it must be designed, not defaulted.
Design decision 1: the SLA, agreed before go-live
The steady-state SLA should be negotiated while the program still has leverage and attention — before go-live, not during hypercare’s closing week. The design spine is the standard service-management priority model: priority derived from a matrix of impact (how many users, how much downtime) and urgency (how quickly it must be resolved), mapping to tiers commonly labeled P1 through P5, each with response and resolution targets attached.
Two traps to avoid. First, copying published example times as targets: the reference response and resolution times you find in vendor materials are illustrative of the shape of a tiered SLA, not benchmarks — the sources that print them say so themselves. Your targets must come from your ticket reality and your business calendar (a payroll fault on payroll-run day is the classic case of low general impact but maximal urgency). Second, negotiating the tiers but not the definitions: if “P1” is whatever the loudest stakeholder says it is, the SLA is decorative. Agree the impact and urgency definitions, in writing, with examples from your own landscape.
Design decision 2: the triage model, running on day one
A tiered SLA presumes a triage machine that categorizes, prioritizes, and routes every ticket — and that machine must exist on AMS day one, not evolve during month one. What has to be agreed pre-go-live: the categorization taxonomy (module, process, interface, data); the priority definitions above; escalation paths with named owners; and — most often missed — the ownership boundary between the residual project team and the AMS desk while both exist in parallel. During hypercare, two support populations run simultaneously; if a ticket’s home is ambiguous, month two inherits the ambiguity as a habit.
Design decision 3: knowledge transfer as a deliverable, not a vibe
The tacit knowledge that walks out with the implementation team is the single largest hidden cost of a badly designed transition. The countermeasure is treating knowledge transfer as defined scope: AMS engagements are commonly structured with an explicit transition/knowledge-transfer phase before steady-state run — which means KT should have a deliverable list (architecture overview, in-scope modules, integration touchpoints, custom developments, runbooks, known-issue log), named recipients, and acceptance criteria. The mechanism that works in practice is phased shadowing: AMS engineers work inside hypercare alongside the project team, taking tickets under supervision, rather than receiving a document dump on the last Friday. Documentation transfers facts; shadowing transfers judgment.
Design decision 4: the agent roadmap, starting at AMS month one
A forward-looking element belongs in the transition design, and we will label it plainly: what follows is IOTEK’s forward design view — a projection of where agentic AI plausibly enters an AMS operating model, not an SAP product claim or roadmap commitment.
The realistic entry points, staged: in month one, retrieval — an agent grounded on the runbooks, known-issue log, and KT materials that the transition just produced, making the knowledge base conversational for the AMS desk rather than archival. Next, triage assistance — proposing category and priority against the agreed taxonomy, with a human dispatcher confirming. Later, as trust and telemetry accumulate: deflection of recurring how-to tickets, and monitoring/anomaly surfacing ahead of user reports. Two design corollaries follow. The KT deliverables double as the agent’s grounding corpus — a second reason to make KT scope rigorous. And the triage taxonomy must be machine-usable from day one, because an agent cannot learn a model that was never written down. Every stage keeps a human owner for actions that touch the system of record; the agent earns scope through measured accuracy, exactly as a new hire would.
The pre-go-live checklist
What should be signed before switch-over: the hypercare duration and its exit criteria (stability evidence, not just a date); the steady-state SLA — tiers, definitions, response versus resolution, coverage windows; the triage taxonomy and escalation ownership, including the project/AMS boundary during the overlap; the KT deliverable list with acceptance sign-off; the hypercare-to-AMS shadowing plan; and the first review checkpoint at which the SLA is recalibrated against the actual ticket mix. That last item is the honest admission every support design should carry: the first version of the SLA is a hypothesis, and month three is when you test it.
Hypercare exit is not the end of the project; it is the first day of the system’s real life. Design the handover — SLA, triage, knowledge, and a labeled-as-projection automation roadmap — before go-live, and month two becomes unremarkable. Leave it to the calendar, and month two is where the support model quietly collapses.