Hypercare Plan: [Solution or release name]
Plan for the period of elevated support that follows a go-live or a
migration cutover: scope and duration, the support model and rota,
the command centre and daily checkpoint, severity targets and
escalation, monitoring focus, known issues and the fix release path,
triage, user support, KPIs and daily reporting, exit criteria, the
handoff to operations and the closure report. Structure aligned with
the hypercare period and handoff described in AWS Prescriptive
Guidance for large migrations and with the hypercare and support
readiness guidance in the Microsoft Dynamics 365 implementation
guide, written for any technology. Replace every [bracketed] value
and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [HYP-001] |
| Solution or release | [Solution name] [Release, wave or rollout] |
| Go-live (end of cutover window) | [YYYY-MM-DD HH:MM time zone] |
| Planned hypercare start | [YYYY-MM-DD HH:MM] |
| Planned hypercare end (target) | [YYYY-MM-DD] |
| Maximum extension without steering approval | [Number] business days |
| Hypercare lead | [@hypercare-lead] |
| Version | [0.1] |
| Status | [Draft / Approved / Active / Extended / Closed] |
| Owner | [@service-owner] |
| Approvers/reviewers | [@business-owner], [@programme-director], [@service-desk-manager], [@solution-architect] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Cutover plan], [Readiness review], [Operations handover plan], [Known issues log] |
Approvals
| Role | Name | Decision | Date |
|---|
| Receiving service owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Business owner | [@name] | [Decision] | YYYY-MM-DD |
| Programme director | [@name] | [Decision] | YYYY-MM-DD |
| Service desk manager | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved before the go-live readiness review |
| 1.1 | YYYY-MM-DD | [@name] | Example: Extended by 5 business days to cover the delayed month-end close |
Contents
1. Scope, objectives and duration
1.1 Scope
| In scope | Out of scope |
|---|
| Example: All processes, interfaces and reports delivered in release 1 for entities DE01 and FR01 | Legacy system look-up access (supported by the legacy team) |
| Example: Data issues arising from the migration | New feature requests (go to the product backlog) |
| Example: User how-to questions and access requests for the new system | Hardware faults on user devices (standard service desk route) |
| [Item] | [Item] |
1.2 Objectives
| ID | Objective | Proved by |
|---|
| HYP-OBJ-001 (Example) | Stabilise the service so that incident volume trends down to a level the operations team can absorb | KPI K-01 and K-02 in section 9 |
| HYP-OBJ-002 (Example) | Complete each critical business event once without a severity 1 or 2 incident | Business event calendar in 1.3 |
| HYP-OBJ-003 (Example) | Transfer working knowledge to the receiving support teams | Reverse-shadow results in the operations handover plan |
| HYP-OBJ-004 (Example) | Close or transfer every go-live condition and known issue | Known issues log at exit |
| [HYP-OBJ-NNN] | [Objective] | [Evidence] |
1.3 Duration and business event calendar
Hypercare starts when the cutover is signed off (Example: Monday 06:00,
T+48h in the cutover plan) and ends when the exit criteria in section 10
are met. For a migration wave of rehosted servers, AWS Prescriptive
Guidance describes a hypercare period that typically lasts 1 to 4 days
before the migration team transfers the workloads to cloud operations. For an enterprise application, plan to cover every
business event in the table below.
| Event | Planned date | Why it matters | Covered? |
|---|
| First full business day (Example) | Day 1 | Volume of logins, access issues, how-to questions | [Yes / No] |
| First overnight batch and interface cycle under real volume (Example) | Day 1 night | Job durations and error handling | [Status] |
| First weekly payment run (Example) | Day 4 | Bank file and approval workflow | [Status] |
| First month-end close (Example) | Days 15 to 18 | Accruals, reconciliations, reporting | [Status] |
| First peak trading day (Example) | Day 20 | Performance under peak load | [Status] |
| [Event] | [Date] | [Reason] | [Status] |
Example: planned duration 20 business days, which covers the
month-end close and the first peak day; target end on day 20.
1.4 Extension rule
Extend hypercare when an exit criterion is not met on the target date.
The hypercare lead proposes the extension with the unmet criteria and a
plan; the service owner approves up to the maximum in Document control;
anything longer goes to the steering committee.
2. Support model and rota
2.1 Support tiers during hypercare
| Tier | Who | Handles | Hours |
|---|
| Floor support | Super-users and floorwalkers at each site | How-to questions, quick fixes, logging tickets for users | Business hours, first 10 days |
| First line | Service desk with hypercare scripts | Intake, categorisation, known-issue matching, access requests | [Service desk hours] |
| Second line | Application support team, paired with project functional experts | Functional and data issues, workarounds, configuration fixes | [Hours], plus on call |
| Third line | Project developers, integration and platform engineers | Code defects, interface failures, performance | [Hours], plus on call for severity 1 and 2 |
| Vendor | Software and platform vendors | Product defects and platform incidents | Per support contract |
2.2 Rota
| Week | Hypercare lead | Functional expert on call | Technical on call | Integration on call | Business contact |
|---|
| Week 1 (Example) | [@name] | [@name] | [@name] | [@name] | [@name] |
| Week 2 (Example) | [@name] | [@name] | [@name] | [@name] | [@name] |
| Week 3 (Example) | [@name] | [@name] | [@name] | [@name] | [@name] |
| Week 4 (Example) | [@name] | [@name] | [@name] | [@name] | [@name] |
Use the On-call Handbook (ops/on-call-handbook) for paging rules and
the Shift Handoff (ops/shift-handoff) record at each shift change.
2.3 RACI
| Activity | Hypercare lead | Service desk | Application support | Project team | Service owner | Business owner |
|---|
| Ticket intake and first response | I | R | C | I | A | I |
| Severity assignment | A | R | C | C | I | C |
| Fix of a code defect | C | I | C | R | A | I |
| Request and implement an emergency change | C | I | C | R | A | C |
| Approval of an emergency change | C | I | C | C | A | C |
| Daily checkpoint and report | R | C | C | C | A | I |
| Extension or exit decision | R | C | C | C | A | C |
The change manager (or emergency change authority) is responsible for
approving an emergency change together with the service owner, as set
out in section 6.2; the project team requests and implements it but
never approves its own change.
3. Command centre, channels and cadence
| Item | Arrangement |
|---|
| Command centre | Example: Room 4.12 in week 1 and 2, then virtual |
| User entry point | Service desk portal and phone; all issues become tickets, including those raised to floorwalkers |
| Hypercare ticket tag | [HYPERCARE-R1] on every ticket for reporting |
| Team channel | [#hypercare-release-name] for coordination, not for issue intake |
| Bridge for severity 1 | [Conference link], opened by the hypercare lead |
| Status page | [Link], updated by the communications lead for incidents with user impact |
3.1 Daily cadence
| Time (Example) | Meeting | Attendees | Output |
|---|
| 08:30 | Triage stand-up (15 min) | Hypercare lead, second and third line leads | New tickets classified, owners set |
| 12:00 | Business pulse (15 min, weeks 1 and 2) | Hypercare lead, super-user leads | Site feedback, training needs |
| 16:30 | Daily checkpoint (30 min) | Hypercare lead, service owner, business owner, project leads | Daily report in section 9, decisions, exit criteria status |
| Weekly | Steering update | Programme director, sponsors | Trend, risks, extension or exit forecast |
Daily checkpoint agenda: incidents by severity since the last checkpoint;
open severity 1 and 2 status; KPI trends; business events in the next
48 hours; fixes ready for release; exit criteria status; decisions
needed.
4. Severity, targets and escalation
| Severity | Definition | Hypercare response | Hypercare update interval | Target to workaround or fix | BAU target after exit |
|---|
| 1 Critical | Critical business process stopped for many users, or data integrity at risk, no workaround | 15 min | 1 h | Workaround within 4 h | [BAU] |
| 2 High | Critical process degraded, or a process stopped for one site or team, workaround is hard | 30 min | 4 h | Workaround within 1 business day | [BAU] |
| 3 Medium | Non-critical process affected, workaround exists | 4 business hours | Daily | Fix planned in a scheduled release | [BAU] |
| 4 Low | Cosmetic issue or question | 1 business day | On change | As capacity allows | [BAU] |
All values in the table are Example targets; replace them with values
agreed with the business owner and recorded in the service level
agreement draft.
4.1 Escalation
| Level | Trigger | Escalate to |
|---|
| 1 | Severity 1 raised, or severity 2 without a workaround after 4 hours | Hypercare lead and service owner |
| 2 | Severity 1 without a workaround after 2 hours | Programme director, business owner, vendor account manager |
| 3 | Severity 1 lasting more than 4 hours or a data integrity issue confirmed | Sponsor; consider the business continuity procedure |
For user and stakeholder messages during incidents, use Incident
Communication (dev/incident-communication).
5. Monitoring focus
| ID | Signal | Source | Threshold or expectation | Checked | Owner |
|---|
| MON-01 (Example) | Orders created per hour against the legacy baseline for the same weekday | Business dashboard | Within 20 % of baseline after day 3 | Hourly in week 1 | Business validation lead |
| MON-02 (Example) | Interface error queue depth per interface | Integration monitor | Zero unprocessed errors older than 1 hour | Continuous alerting | Integration lead |
| MON-03 (Example) | Batch job completion and duration | Scheduler | Complete within rehearsal duration plus 25 % | Each morning | Platform lead |
| MON-04 (Example) | Response time of the five most used transactions | Application performance monitoring | Within the tested targets | Continuous | Technical lead |
| MON-05 (Example) | Workflow items waiting for approval | Workflow report | No item older than 2 business days | Daily | Functional lead |
| MON-06 (Example) | Data quality checks on new records (missing tax codes, duplicate partners) | Data quality report | Zero failures for mandatory rules | Daily | Data lead |
| MON-07 (Example) | Logins per site and active users against expected users | Usage analytics in the application | At least 90 % of expected users active by day 5 | Daily | Change lead |
| MON-08 (Example) | Security events for new roles and privileged access | Security monitoring | Alerts triaged the same day | Continuous | Security lead |
| [MON-NN] | [Signal] | [Source] | [Expectation] | [Frequency] | [@owner] |
Make sure alerts route to the hypercare rota from the first minute and
are re-routed to the operations rota at exit. See Observability
Specification (ops/observability-spec).
6. Known issues and fix release path
6.1 Known issues log
| ID | Description | Origin | Workaround | Users informed | Fix target | Owner | Status |
|---|
| KI-001 (Example) | Report R-17 slow at peak | Readiness defect DEF-0398 and condition GLC-03; cutover decision CD-001 | Scheduled at 05:00 | Yes, day 0 notice | Hypercare release 2 | [@name] | [Open / Fixed / Transferred] |
| KI-002 (Example) | Credit note layout misses one tax line for FR01 | Readiness defect DEF-0412, fix slipped past T-3d | Manual credit note template | Yes | Hypercare release 1 | [@name] | [Status] |
| [KI-NNN] | [Description] | [Source] | [Workaround] | [Yes / No] | [Release] | [@owner] | [Status] |
6.2 Fix release path
| Path | Use for | Approval | Testing | Cadence |
|---|
| Emergency change | Severity 1 fix or a workaround that needs a change | Service owner plus change manager, recorded after the fact within 1 business day if needed | Targeted test in pre-production; regression of the affected process | Any time |
| Hypercare release | Severity 2 and 3 fixes, bundled | Change advisory board, fast-track slot | Regression suite plus business re-test | Example: Twice a week, Tuesday and Thursday 19:00 |
| Standard release | Severity 4, improvements, change requests | Normal change process | Full test cycle | Product release calendar |
Keep the code and configuration freeze from the cutover plan in place
until the first hypercare release; after that, only the paths above may
change production. Raise changes with Change Request (ops/change-request).
7. Triage and classification
| Class | Definition | Route | Counts toward defect KPI? |
|---|
| Defect | The solution does not behave as specified | Third line, fix release path | Yes |
| Data issue | Migrated or newly entered data is wrong or incomplete | Data lead; data fix by approved script | No, reported separately |
| Configuration issue | Setup differs from the design | Second line, change record | Yes |
| Training or how-to | The solution works; the user needs help | First line or floor support; feeds training top-ups | No |
| Access request or issue | Missing or wrong role | Access management | No |
| Change request | A new or different requirement | Product backlog with business owner | No |
| Infrastructure or vendor incident | Fault outside the application | Platform team or vendor | No, reported separately |
Open a problem record for every severity 1 and for any pattern of three
or more related tickets. Use Postmortem (dev/postmortem) for severity 1
incidents.
8. User support and adoption
| Measure | Arrangement |
|---|
| Floorwalkers | Example: Two per site in week 1, one per site in week 2; each carries a tablet to log tickets |
| Super-user network | Named per team; daily 15-minute call in weeks 1 and 2 |
| Quick reference | One-page guides per role, linked from the application home page |
| FAQ | Updated daily from ticket themes; published on the intranet |
| Training top-ups | Short sessions scheduled when one topic produces more than [number] tickets in a day |
| Feedback | Daily site pulse at 12:00 in weeks 1 and 2; weekly survey of super-users |
| Business continuity | Manual fallback procedures from the readiness review remain available until exit |
9. KPIs and daily reporting
9.1 KPIs
| ID | KPI | Definition | Target at exit (Example) |
|---|
| K-01 | New incidents per day | Tickets tagged HYPERCARE, all classes, opened per business day | Five consecutive days at or below the level operations can absorb, agreed as [number] per day |
| K-02 | Open severity 1 and 2 | Count of open severity 1 and 2 incidents | Zero severity 1; severity 2 only with an accepted workaround |
| K-03 | Backlog age | Open tickets older than 5 business days | Fewer than [number] |
| K-04 | First-line resolution share | Tickets resolved by first line without escalation | At least [percentage] |
| K-05 | Business throughput | Key business volume against baseline (MON-01) | Within normal range for 5 consecutive days |
| K-06 | Batch and interface success | Successful runs divided by scheduled runs | At least [percentage] for 5 consecutive days |
| K-07 | Active users | Active users divided by expected users | At least [percentage] |
9.2 Daily report
| Field | Value |
|---|
| Date and hypercare day | YYYY-MM-DD, day [N] of [planned N] |
| Overall status | [Green / Amber / Red] with one-sentence reason |
| New tickets today (by class) | [Defect N, data N, training N, access N, change N, other N] |
| Open severity 1 / 2 / 3 / 4 | [N / N / N / N] |
| Incidents of note | [ID and one line each] |
| KPI trend | [K-01 to K-07 with arrow up, down or flat] |
| Fixes released today, fixes planned | [Release ID and KI IDs] |
| Business events in the next 48 hours | [Events] |
| Exit criteria met | [N of N] |
| Decisions needed | [Decision, owner, date] |
10. Exit criteria
| ID | Criterion | Evidence | Confirmed by | Status |
|---|
| HYP-EX-001 (Example) | No open severity 1; every open severity 2 has an accepted workaround and a fix date | Ticket report | Service owner | [Met / Not met] |
| HYP-EX-002 (Example) | K-01 at or below the agreed level for 5 consecutive business days | KPI report | Hypercare lead | [Status] |
| HYP-EX-003 (Example) | All business events in section 1.3 completed once without severity 1 or 2 | Business event calendar | Business owner | [Status] |
| HYP-EX-004 (Example) | Batch and interface success at target for 5 consecutive days | Scheduler and integration reports | Platform lead | [Status] |
| HYP-EX-005 (Example) | Every known issue fixed, or transferred to operations with an owner and a date | Known issues log | Service owner | [Status] |
| HYP-EX-006 (Example) | Receiving teams handled tickets unaided in reverse shadow for at least 5 business days | Operations handover plan results | Application support lead | [Status] |
| HYP-EX-007 (Example) | Monitoring and alerts re-routed to the operations rota and tested | Alert test record | Operations lead | [Status] |
| HYP-EX-008 (Example) | Documentation pack accepted by operations | Operations handover acceptance | Service owner | [Status] |
| [HYP-EX-NNN] | [Criterion] | [Evidence] | [@name] | [Status] |
The service owner declares exit when all criteria are met, or when the
remaining ones are waived in writing with a transfer plan.
11. Handoff to operations
| ID | Item | Status | Notes |
|---|
| HO-01 (Example) | Open tickets reassigned from project queues to operations queues | [Done / Not done] | [Count] |
| HO-02 (Example) | Known issues and problem records transferred with owners and dates | [Status] | [IDs] |
| HO-03 (Example) | Alert routing, on-call rota and escalation contacts switched to operations | [Status] | [Test reference] |
| HO-04 (Example) | Project access removed or reduced; vendor access under operations control | [Status] | [Access review reference] |
| HO-05 (Example) | Runbooks updated with hypercare lessons | [Status] | [Links] |
| HO-06 (Example) | Service level targets switched from hypercare to BAU in the ITSM tool | [Status] | [Date] |
| HO-07 (Example) | Warranty or early life support terms confirmed with the delivery team | [Status] | [Contract reference] |
| HO-08 (Example) | Stakeholders notified that hypercare is complete and of the support route | [Status] | [Message reference] |
| [HO-NN] | [Item] | [Status] | [Notes] |
The detailed knowledge transfer, shadowing and acceptance into service
are in Operations Handover and Knowledge Transfer (ops/operations-handover).
12. Risks
| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|
| HYP-R-001 (Example) | Project experts leave for the next rollout before exit | Medium | High | Named experts released only at exit; backfill plan approved | Programme director |
| HYP-R-002 (Example) | Peak season raises volume before stabilisation | Medium | High | Performance watch MON-04; extra capacity booked for weeks 3 and 4 | Technical lead |
| HYP-R-003 (Example) | Users bypass the system with spreadsheets | Medium | Medium | Floorwalker reports; business owner messages; quick fixes for the pain points | Change lead |
| HYP-R-004 (Example) | Fix releases introduce regressions | Low | High | Regression suite on every hypercare release | Test lead |
| [HYP-R-NNN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |
13. Closure report
| Field | Value |
|---|
| Hypercare dates | [Start] to [end], [N] business days (planned [N]) |
| Extensions | [None / N days, reason] |
| Tickets by class and severity | [Table or link] |
| Severity 1 incidents | [Number, IDs, postmortem links] |
| Defects fixed during hypercare | [Number, releases] |
| Items transferred to operations | [Number of tickets, known issues, problems] |
| KPI values at exit | [K-01 to K-07] |
| Business events completed | [List] |
| Effort used | [Person-days by team] |
| Lessons for the next rollout | [Summary; full list in lessons learned] |
| Signed off by | [@service-owner], [@business-owner], YYYY-MM-DD |
Record lessons in Lessons Learned (project/lessons-learned) and
schedule the Post-Implementation Review
(project/post-implementation-review).
14. Glossary and references
14.1 Glossary
| Term | Meaning in this plan |
|---|
| Hypercare | Period of elevated, time-limited support right after go-live |
| Command centre | Physical or virtual hub where the hypercare team coordinates |
| Floorwalker | Person who supports users at their desks or sites in the first days |
| Known issue | Problem known at or after go-live with a documented workaround |
| Emergency change | Change made urgently to restore service, with lighter approval and later review |
| Exit criteria | Measurable conditions that end hypercare |
| BAU | Business as usual: the normal support model after hypercare |
| Reverse shadow | Receiving team does the work while the project team observes |
14.2 References
| Reference | Version or date checked | Use |
|---|
| AWS Prescriptive Guidance, Introduction to governance for large migrations, preparing the organization (hypercare period), docs.aws.amazon.com | Web edition checked 2026-10-23 | Hypercare as a short post-cutover period ending in a handoff checklist with cloud operations |
| AWS Prescriptive Guidance, Project governance playbook for AWS large migrations (gates 8 and 9: hypercare start and end), docs.aws.amazon.com | Initial publication 2022-02-28 | Hypercare start and end notices |
| Microsoft Dynamics 365 implementation guide, go-live checklist (operational support readiness), learn.microsoft.com | Page updated 2026-07-15 | Hypercare as elevated support after go-live, paraphrased |
| Microsoft Dynamics 365 implementation guide, create a support strategy, learn.microsoft.com | Page updated 2026-07-15 | Support scope, team and operations themes |
| ISO/IEC 20000-1:2018, Service management system requirements, clause 8.6 (resolution and fulfilment) | Edition 2018, confirmed 2023; Amd 1:2024 | Incident and request handling alignment |
| [Internal ITSM process] | [Version] | [Severity definitions] |
Standard and licence note
Structure aligned with the hypercare period and handoff described in
AWS Prescriptive Guidance for large migrations, with the hypercare and
support readiness guidance in the Microsoft Dynamics 365
implementation guide, and with the incident and request clause
structure of ISO/IEC 20000-1:2018. Clause numbers and guidance titles
are cited for mapping; no vendor text, checklist item or ISO text is
reproduced. Amazon Web Services, AWS, Microsoft and Dynamics 365 are
trademarks of their owners; this template is not affiliated with or
endorsed by them. This template is original text written for this
collection. Check the current official guidance and standard versions
before use. Template licence: MIT.