After the Cutover Switch: What Really Happens Once Your Azure Move Goes Live
Cutover is the moment everyone plans for. The runbook has been executed, the final replication delta is applied, DNS or traffic routing is switched, and the war room slowly empties. Then the harder question arrives: what now? Experienced teams treat go-live as one stage in a longer process rather than a finish line, because the hours, days and weeks that follow decide whether the new environment actually delivers the performance, security posture and cost profile the business case promised. Identity behaviour under real traffic, dependency quirks that never surfaced in test, and the first Azure bill for resources sized generously during migration all show up after the switch, not before it. For IT leaders planning a move — or already holding a cutover date — understanding that post-cutover phase, and specifically who owns each part of it, matters as much as the migration plan itself.
Hypercare: The 30 to 90 Day Window That Decides Whether Go-Live Holds
Hypercare is the structured period immediately after cutover when the migration team stays closely engaged with the environment rather than handing it over and walking away. In a well-run program it typically runs 30 to 90 days after go-live, and its purpose is to absorb the surprises that only real production traffic can expose. However thorough the pre-migration assessment was, some behaviour is impossible to replicate in a pilot: peak concurrency patterns, a batch job that assumes a specific latency between two servers, a scheduled task that relied on an undocumented credential, or an application that degrades gracefully on legacy hardware but not on a freshly provisioned Azure VM.
The first task inside hypercare is establishing a monitoring baseline and comparing it against the pre-migration baseline captured before the move. This is how teams answer the question that matters most to the business: did the move cost the application any performance? Response times, error rates, CPU and memory saturation, storage IOPS, database query timings and network throughput are all tracked against the old numbers, not against an abstract ideal. Deviations become engineering tickets with owners and deadlines rather than vague complaints.
Incident handling during this window also needs a clear shape. Teams should know the escalation path, the on-call rota, and the criteria for fix-forward versus rollback. Rollback readiness is normally maintained for a defined period after cutover — usually tied to a data consistency checkpoint and a business-agreed retention window — because a reversible cutover is what makes the decision to proceed low-risk in the first place. Once that window closes, rollback stops being the safety net and the forward path becomes the only path, which is a transition worth scheduling explicitly rather than discovering by accident.
Hypercare is also where security posture gets tested in anger. Hardened landing zones and Defender for Cloud policies that looked correct in design may generate false positives that swamp a security team, or reveal gaps in private networking, Key Vault access policies, or WAF rule tuning once genuine traffic flows through App Gateway. Organisations that engage experienced azure cloud migration services with a defined post-go-live phase usually find this period is staffed, scheduled and reported on, with daily or weekly checkpoints against a written exit criteria list rather than an open-ended “we’ll keep an eye on it” arrangement.
Performance Tuning, Security Hardening and Cost Rightsizing Under Real Traffic
Cost shock after go-live is one of the more common ways an Azure migration disappoints. The cutover works, the lights stay on, and then the first invoices arrive for resources nobody sized properly. During a migration, sizing is deliberately conservative — teams over-provision to protect the cutover and avoid a performance incident during the most visible week of the project. That is the right instinct at the time, but it is not a steady state. Post-cutover is when rightsizing reviews begin: matching VM SKUs to observed utilisation, right-sizing Azure SQL tiers, reviewing storage redundancy choices, and identifying idle or orphaned resources left behind by the migration itself.
Rightsizing alone is a one-off exercise, which is why FinOps governance belongs alongside it. That means tagging standards so costs can be attributed to a workload or business unit, budget alerts and anomaly detection so a runaway resource is caught in days rather than at quarter end, and a repeating review cadence with named owners. Savings from a migration arrive later than the migration costs, as lower infrastructure and operating costs accumulate — but only if someone is actively managing the consumption curve. Without governance, the environment drifts upward quietly.
Performance tuning runs in parallel. Applications lifted as-is often carry legacy inefficiencies that were masked by the old platform or amplified by the new one: chatty database calls that now cross an availability zone boundary, connection pooling tuned for a single server, or autoscaling rules that were configured but never validated. Load balancer and App Gateway health probe settings, caching layers, and backup schedules all need review against real patterns. For workloads that moved with Azure Migrate or Azure Database Migration Service, the migration tooling did its job at cutover; tuning is a different discipline entirely.
Security hardening follows the same rhythm. Defender for Cloud recommendations get triaged, Sentinel analytics rules are tuned to reduce noise, WAF rules move from detection to prevention where false positives have been cleared, and privileged access granted for the migration is reviewed. Templates built in Terraform, Bicep or ARM should be updated to reflect every manual fix made during hypercare, so that the infrastructure-as-code definition matches reality and the next deployment does not reintroduce a problem that was already solved under pressure.
Handover, Documentation and Access Cleanup: Leaving Your Team in Control
A good migration ends with the internal team able to run the environment without depending on the people who built it. That outcome is engineered during handover, not hoped for afterwards. The tangible deliverables are unglamorous and decisive: runbooks covering routine operations and known failure modes, current architecture diagrams, a workload inventory with owners and dependencies, documented backup and restore procedures, monitoring dashboards with alert thresholds explained, and knowledge transition sessions where the receiving team asks questions while the migration specialists are still available.
Access cleanup is often the most neglected item on that list. Migration work leaves a trail of temporary access: engineer accounts with elevated rights, service principals created for replication, firewall rules opened for Azure Migrate appliances, shared credentials in a wiki, and legacy DNS entries pointing at decommissioned systems. Each one is an audit finding waiting to happen. Post-cutover is the right time to remove what is no longer needed, confirm that Key Vault holds what it should, and verify that only the intended identities can reach production. The same applies to decommissioning legacy infrastructure — scheduling it after an agreed retention period rather than leaving it running and billed indefinitely.
Ownership questions should be settled before signing rather than after go-live: who owns each phase, what gets documented, and what support exists once the project closes. Organisations that asked those questions up front tend to receive a complete handover package with clear escalation paths, while those that did not often discover gaps only when an incident occurred at an inconvenient hour. Ongoing support arrangements matter here too — 24/7 coverage, defined response expectations, and premium tiers that add dedicated communication channels and direct messaging access make the difference between a safety net and a phone number.
Not every organisation needs the same level of post-cutover involvement. Some want a short hypercare window and then full independence; others prefer managed support after go-live so the same people who planned the migration keep operating it. Container estates on AKS, ACR and Container Apps usually need a different handover emphasis than a set of Windows and Linux servers, and .NET applications that were modernised rather than lifted require their own deployment and rollback documentation. Whichever route fits, the test is the same: if the migration specialists stepped away tomorrow, could the internal team keep the environment secure, performant and predictable on cost? If the answer is yes, the migration genuinely finished — not just the cutover.
Marseille street-photographer turned Montréal tech columnist. Théo deciphers AI ethics one day and reviews artisan cheese the next. He fences épée for adrenaline, collects transit maps, and claims every good headline needs a soundtrack.
Théo Legrand
Marseille street-photographer turned Montréal tech columnist. Théo deciphers AI ethics one day and reviews artisan cheese the next. He fences épée for adrenaline, collects transit maps, and claims every good headline needs a soundtrack.
