Before starting the cutover, ensure Steps 1–3 (Environment Assessment, Infrastructure Provisioning, and Data Migration) are fully completed and validated. Your CloudNexus environment should be fully provisioned and your data synchronized.
The application cutover is the critical phase where live traffic transitions from your existing infrastructure to CloudNexus. Our recommended approach uses a phased cutover strategy to minimize downtime and risk. Typical cutover windows range from 15 to 60 minutes depending on your architecture complexity.
Cutover Strategy Overview
CloudNexus supports three cutover strategies depending on your risk tolerance and SLA requirements:
| Strategy | Downtime | Complexity | Best For |
|---|---|---|---|
| Big Bang | 15–30 min | Low | Simple apps, maintenance windows |
| Phased (Recommended) | 0–5 min | Medium | Most production workloads |
| Blue-Green | Zero | High | Zero-downtime requirements |
For most production environments, we recommend the Phased Cutover strategy. It provides a good balance between speed, safety, and operational complexity. The following steps detail this approach.
Pre-Cutover Checklist
Complete every item on this checklist before initiating the cutover window. Any uncompleted items should be escalated to your CloudNexus Solutions Architect.
- Infrastructure provisioned and health-checked on CloudNexus
- Data migration completed with final delta sync verified
- Application deployed and smoke tests passing on CloudNexus
- DNS records identified and TTLs reduced to 300s (1 hour prior)
- Load balancer configured and health checks passing
- SSL/TLS certificates provisioned and validated
- Monitoring dashboards and alerting configured
- Rollback procedure documented and tested
- Stakeholder notification sent to all teams
- War room / bridge call established with key personnel
Cutover Execution Steps
The following steps should be executed sequentially during the cutover window. Each step includes validation criteria before proceeding to the next.
Enable maintenance mode on your origin infrastructure to prevent new write operations. This ensures data consistency during the final sync.
Use the CloudNexus CLI to trigger maintenance mode on your load balancer:
Validation: Confirm that active_connections equals 0 and the origin is returning HTTP 503 responses.
Run the final delta synchronization to capture any data changes that occurred during the maintenance mode setup. This is the last data transfer before cutover.
If the checksums do not match, abort the cutover and re-run the sync. Do not proceed with traffic switching until data integrity is confirmed.
Validation: Checksums must match between source and target. All replication lag metrics should read 0.
Update your DNS A/AAAA records to point to your CloudNexus global load balancer IP. Since TTLs were reduced earlier, propagation will occur within minutes.
Validation: All global DNS locations must resolve to the CloudNexus IP address.
Switch the CloudNexus load balancer from drain mode to active, beginning to accept and route live traffic to your application.
Validation: All backend nodes report healthy status with latency under 10ms.
Gradually shift traffic from the origin to CloudNexus using weighted routing. This allows you to monitor application behavior under real load and catch issues early.
Validation: At each phase, verify error rates are below 0.1% and latency is within acceptable thresholds. If errors spike, hold at the current weight and investigate.
Once 100% of traffic is confirmed flowing through CloudNexus, disable the origin infrastructure and remove it from the load balancing pool.
Validation: The cutover-complete command must return all green checkmarks. Archive the cutover log for your records.
Expected Cutover Timeline
Rollback Procedures
Initiate a rollback if any of the following occur: error rate exceeds 1%, P99 latency exceeds 2× baseline, data corruption is detected, or critical features are non-functional on CloudNexus.
If a rollback is required, execute the following steps in order. The goal is to restore traffic to the origin as quickly as possible.
Important: After a rollback, the CloudNexus environment remains provisioned and ready. Resolve the identified issues and reschedule the cutover. Your Solutions Architect will conduct a post-mortem to determine root cause.
Post-Cutover Monitoring
After a successful cutover, maintain elevated monitoring for at least 2 hours. Key metrics to watch:
- HTTP Error Rates: Must remain below 0.1%. Watch for 5xx errors specifically.
- Latency Percentiles: P95 and P99 should be within 10% of pre-cutover baselines.
- Database Connection Pool: Monitor for connection spikes or exhaustions.
- Cache Hit Rates: Verify that CDN and application caches are warming correctly.
- Application Logs: Watch for new error patterns or warnings in CloudWatch / Datadog.
- Business Metrics: Conversion rates, API throughput, and user session data.
CloudNexus provides a Cutover Dashboard accessible from your console that aggregates all these metrics into a single view. Your Solutions Architect can add custom dashboards for application-specific KPIs.
If all monitoring checks pass after 2 hours, your cutover is considered successful. Proceed to Step 5: Post-Migration Validation for comprehensive testing and optimization.
Best Practices
Schedule During Low Traffic
Plan your cutover during your lowest traffic period, typically between 2:00 AM – 5:00 AM in your primary region. Use historical traffic data from the CloudNexus migration assessment to identify the optimal window.
Reduce TTLs Early
Reduce DNS TTLs to 300 seconds (5 minutes) at least 1 hour before the cutover window. This ensures rapid propagation when records are updated. Do not go below 300s as some recursive DNS resolvers may ignore lower values.
Test the Rollback
Perform a dry-run of the rollback procedure during a staging migration. Verify that traffic can be restored to the origin in under 5 minutes.
Communicate Proactively
Notify all stakeholders (engineering, support, marketing, executive team) at least 48 hours before the cutover. Include the expected downtime window, rollback criteria, and contact information for the war room.
Keep the Origin Warm
Do not decommission the origin infrastructure immediately after cutover. Keep it running in a reduced state for at least 7 days as a rollback safety net.