India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cutover and Hypercare: Go-Live Runbooks, Rollback Points and War Rooms
Cutover and hypercare is the go-live phase of a migration: the timed runbook that switches users to the cloud system, the go/no-go and rollback decision points, and the 2-4 weeks of heightened support afterwards. NTSPL writes minute-level runbooks, runs dress rehearsals, staffs a war room during the switch, and closes hypercare against agreed exit criteria.
Delivered on
In scope
Where Migration Go-Lives Actually Go Wrong
Most of a migration's risk sits in a few hours. A hotel's property management system, a bus operator's seat inventory or a factory's dispatch app must stop, sync, switch and restart while the business waits. The common failures are predictable: the final data sync runs longer than tested, a partner's IP whitelist was not updated, the rollback point was never defined, and the team that knows the app is asleep when the issue appears at 6 a.m. on Monday.
NTSPL treats cutover as a rehearsed event. Every step has an owner, a start time, a duration from rehearsal and a check. Go/no-go gates are written in advance with measurable criteria, and the point of no return is named and timed. After the switch, hypercare runs with a war room, daily defect triage and a business sign-off checklist, and ends only when exit criteria are met, not on a calendar date.
Systems That Need a Formal Cutover Plan
Signals you need Cutover & Hypercare
- The system is customer-facing or revenue-critical and allows less than four hours of downtime.
- External partners, such as OTAs, banks, OEMs or government portals, connect to it.
- The final data sync or database switch takes more than 30 minutes.
- A previous go-live overran its window or was rolled back.
When to choose something else
- For low-risk internal servers with simple restarts, a standard wave runbook from the factory is enough.
- If the target environment has not passed functional and load testing, fix that first; cutover planning cannot make up for an unready system.
Runbooks, Rehearsals, Decision Gates and Hypercare
Cutover runbook
Minute-level steps with owner, duration, verification and dependencies, from freeze to business sign-off.
Dress rehearsals
At least one full rehearsal on production-like data, timed and used to adjust the runbook.
Go/no-go gates
Written criteria at set points: readiness, data validation, smoke test and business test.
Rollback plan
Named rollback steps, the point of no return and the data reconciliation needed after it.
Hypercare
War room, extended monitoring, daily triage, and exit criteria agreed with the business.
How Cutover & Hypercare Works, Step by Step
Rehearse-Switch-Stabilise Go-Live Model
Rehearsals set timings for the runbook and gates. On the night, the switch moves through gated steps up to a timed point of no return, and hypercare monitors and fixes issues until exit criteria are met.
Select any component
Rehearse-Switch-Stabilise Go-Live Model: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Traffic Switching and Monitoring Tools by Cloud
Route 53 weighted records allow a gradual traffic shift, and Systems Manager Automation runs scripted runbook steps with logged outputs.
Traffic Manager or Front Door weights shift users in steps, and Azure Monitor workbooks give the war room one view of health.
Cloud Load Balancing traffic splitting supports canary switches, with Cloud Monitoring dashboards and uptime checks for the war room.
Cutover Choices: Big Bang, Phased, Rollback Point
Big bang or phased cutover
Use big bang when data is shared across all users and cannot be split, such as a single PMS or seat inventory; keep the window as short as rehearsal allows. Use phased cutover by site, user group or traffic percentage when the system can run partly on each side. A 5%, 25%, 100% traffic shift over two days catches issues while impact is small.
Defining the point of no return
The point of no return is when new transactions in the cloud system would be lost by rolling back. Time it from rehearsal, place it after the business smoke test, and make sure leadership knows the clock time. After it, rollback requires reverse sync or re-entry, so plan that path too, even if it is never used.
Go/no-go criteria
Write measurable criteria: row counts match, smoke test of 15-30 key transactions passes, partner connections confirmed, error rate below a threshold. Name one approver per gate and a deputy. Avoid vague criteria such as 'system looks fine'. If a criterion fails and the fix will take longer than the remaining buffer, roll back.
Hypercare length and exit
Plan two weeks for most systems and four for those with month-end processes, so one full close happens in hypercare. Exit when there are no open severity 1 or 2 defects, performance meets baseline for seven days, and the business owner signs off. Shorten or extend based on these criteria, not the calendar.
Go-Live Timeline from Rehearsal to Hypercare Exit
Runbook and gate design
Steps, owners, timings, gates and rollback path written.
Dress rehearsals
One or two full rehearsals timed, runbook updated each time.
Readiness review
Partners, users and leadership briefed; final go/no-go scheduled.
Cutover event
Freeze, sync, gates, switch, smoke test, business sign-off.
Hypercare and exit
War room, triage, tuning and handover to operations at exit.
What you receive
Go-Live and Hypercare Exit Measures
| KPI | Typical target |
|---|---|
| Cutover finished within planned window | Yes, with buffer unused or partly used |
| Rehearsal-to-actual timing variance | Under 20% |
| Severity 1 incidents in hypercare | Zero after the first 72 hours |
| Hypercare exit | Within planned period |
Cutover Failures That Rehearsal Prevents
| Risk | How NTSPL prevents it |
|---|---|
| Final sync takes much longer than planned on real data volumes. | Rehearsals use production-sized data, and 50% buffer is added to data steps. |
| A partner's whitelist or endpoint is not updated, breaking an integration. | Partner checklist is confirmed in writing a week ahead, with a test call before go-live. |
| Key people are unavailable when an issue appears after go-live. | Hypercare roster with named on-call people for 72 hours, including vendor contacts. |
How long should hypercare last after a migration go-live?
Two weeks suits most systems, and four weeks suits those with month-end or billing cycles, so one full cycle runs under close watch. But the length should follow exit criteria, not the calendar: no open severity 1 or 2 defects, performance at or above baseline for seven days, and business sign-off. Ending hypercare early to free the team usually means the first month-end becomes an incident. Extending it indefinitely is also a warning sign that defects are not being fixed, so set a review point at the planned end date.
Key facts: Cutover & Hypercare
Cutover & Hypercare in Practice
2 Cutover & Hypercare scenarios, from Luxury hotel and Intercity bus operator, plus related platform case studies.
Luxury hotel switches its PMS and 14 interfaces to AWS in a 3-hour overnight window
Private bus operator moves seat inventory to Google Cloud with a phased 5-25-100 switch
Telecom VAS provider cuts daily pages from 2,300 alerts to 9 actionable incidents
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Cutover & Hypercare: Frequently Asked Questions
What is a cutover runbook?
It is a timed, step-by-step plan for go-live: each step with an owner, start time, expected duration from rehearsal, a check, and what to do if it fails. A typical runbook for a business-critical system has 80-200 steps from change freeze to business sign-off.
How many rehearsals do we need?
At least one full dress rehearsal on production-sized data. For systems with external partners or more than two hours of planned downtime, two rehearsals are better. The second usually cuts actual timing by 20-30% because steps are refined. Rehearse at the real time of day.
What does cutover and hypercare support cost?
For one business-critical system, planning, rehearsals, the cutover event and two weeks of hypercare typically cost INR 4-12 lakh, depending on team size and hours. Night and weekend cutovers and 24x7 war rooms increase the cost. Rehearsals are usually the best-value line.
When should we roll back?
When a go/no-go criterion fails and the fix will not fit in the remaining buffer before the point of no return. Rollback should be a calm, planned decision, which is why the criteria and approvers are written in advance. Nobody improvises at 4 a.m.
How do you handle incidents during hypercare for CERT-In?
The war room includes the security contact, and the incident path is set up so cyber incidents can be assessed and reported to CERT-In within six hours if required. Logs are retained in India for 180 days from the first day in cloud.
Can you schedule cutovers around Indian holidays and peaks?
Yes. We avoid festive peaks, month and quarter closes, GST filing dates and sector-specific busy periods, such as wedding season for hotels or festival travel for bus operators. The cutover date is set from the business calendar first. Partners' freeze dates are added too.