Cloud migrations are among the highest-risk operational windows your engineering team will execute. You're simultaneously changing DNS records, swapping load balancers, reissuing certificates, migrating data, and cutting over traffic — often under time pressure, often with limited rollback windows.
The failure modes are well understood: a DNS TTL that didn't fully propagate, a load balancer health check misconfigured, a database that's out of sync at cutover, a certificate that wasn't reissued on the new host. Any of these turns a planned migration into an unplanned incident.
Uptime monitoring isn't just a nice-to-have during migrations. With the right setup, it becomes your real-time signal for whether each stage of the cutover is working — and your rollback trigger when something goes wrong.
Why Cloud Migrations Are Peak Risk for Availability
Before getting to the monitoring setup, it's worth naming the specific failure modes migrations introduce:
DNS changes with residual TTL propagation
When you update DNS to point to a new load balancer or IP, records take time to propagate based on TTL values set on the old records. If you set a 5-minute TTL before migration but users have cached 24-hour TTL values, some users will still route to your old infrastructure for hours after cutover. Monitoring only the new endpoint won't tell you this.
Load balancer cutover timing
The moment you move traffic from one load balancer to another, there's a window where in-flight connections may be dropped or sessions invalidated. Monitoring the upstream DNS target doesn't capture this — you need direct endpoint checks on both the old and new targets.
Certificate reissuance failures
Your new cloud environment needs its own SSL certificate. Provisioning usually works, but edge cases exist: ACME challenge failures if DNS propagation is partial, certificate chain mismatches if you're using a different CA, or simply a misconfigured domain binding. Certificate expiry monitoring on the new endpoint catches this before users hit browser security warnings.
Data sync lag at cutover
If you're running a source and target database in parallel and cutting over at a sync checkpoint, there's a window where in-flight writes on the source haven't replicated to the target. Monitoring can't directly observe database sync state, but heartbeat monitoring on your sync jobs gives you a real-time signal that sync is still running.
Setting Up Parallel Monitoring: Monitor Both Source and Target
The single most important monitoring setup for a migration is parallel monitoring: simultaneous checks on both your source (old) infrastructure and your target (new) infrastructure throughout the migration window.
Source monitors:
- HTTP check on your existing production URL (catches if you've broken existing traffic during prep)
- TCP port check on your existing database port (if accessible)
- SSL certificate monitor on your current domain
Target monitors:
- HTTP check on your new load balancer URL or IP (verifies new infrastructure is responding before DNS cutover)
- HTTP check on your new domain URL (post-DNS-cutover verification)
- SSL certificate monitor on the new domain
With Vigilmon, set up both sets of monitors before the migration window begins. Use 1-minute check intervals during the migration window — the default 5-minute interval is too slow to catch and respond to failures during a live cutover.
During the migration:
- Both source and target monitors should show healthy simultaneously until you cut over
- At cutover, the target monitors should immediately pick up health signals
- Source monitors staying healthy after cutover confirms you haven't broken rollback capability
- Target monitors going down at cutover is your signal to rollback before the situation worsens
Heartbeat Monitoring for Migration Scripts and Data Sync Jobs
Migration scripts are some of the most operationally critical code you'll run — and also some of the hardest to monitor. A migration script that silently hangs doesn't fire any alert unless you've set up explicit monitoring.
Heartbeat monitoring inverts this problem: your migration script pings a heartbeat endpoint at the completion of each phase. If Vigilmon doesn't receive the expected ping within the configured timeout, it alerts immediately.
Example setup for a multi-phase data migration:
# Phase 1: user data migration
migrate_users.sh && curl -s https://hb.vigilmon.online/[token]/phase1
# Phase 2: order history migration
migrate_orders.sh && curl -s https://hb.vigilmon.online/[token]/phase2
# Phase 3: media assets migration
migrate_assets.sh && curl -s https://hb.vigilmon.online/[token]/phase3
Configure each heartbeat with a timeout appropriate for the expected phase duration. If phase 1 normally takes 20 minutes, set a 30-minute timeout. If Vigilmon doesn't see the ping by then, it alerts your team.
This gives you:
- Confirmation each migration phase completed successfully
- Immediate alert if a phase hangs or fails
- A timeline of migration phase completion that's useful for post-migration review
Aggressive Alert Thresholds During Migration Windows
During normal operations, a slightly elevated response time or a 5-second blip might not warrant immediate attention. During a migration window, any anomaly is signal — you want to know about it immediately, not after 3 failed checks.
Configure Vigilmon during your migration window with:
- Check interval: 1 minute (minimum available)
- Alert on first failure: enable immediate alerting without waiting for confirmation from multiple checks
- Response time threshold alerts: set aggressive thresholds (e.g. alert if response time exceeds 2 seconds, not the normal 10-second default)
- Multiple alert destinations: Slack AND email AND PagerDuty/on-call — the migration team needs immediate, redundant notification
After the migration window closes and you've verified stable operation, revert to normal alert thresholds.
Defining Rollback Triggers Based on Monitor Failures
Rollback decisions made under pressure during a live incident are dangerous. Define your rollback triggers before the migration begins, based on specific monitoring signals.
Example rollback decision matrix:
| Signal | Trigger | Action | |---|---|---| | Target HTTP check fails | 3+ consecutive check failures from multiple regions | Immediate rollback — revert DNS | | Target SSL check fails | Certificate error returned | Rollback + fix certificate | | Source HTTP check fails during prep | Any failure | Stop migration — fix source first | | Heartbeat missed for phase N | Timeout exceeded by 20% | Pause migration — investigate phase N | | Response time > 5s sustained | 5+ consecutive checks | Investigate — consider rollback |
Writing these triggers down before the migration window means the on-call engineer has a clear decision framework instead of making judgment calls under pressure. The monitors provide objective signals; the triggers define when those signals require action.
Post-Migration Verification Checklist
Once the migration cutover is complete and initial monitoring shows healthy, run a structured verification before declaring the migration done:
Endpoint verification:
- [ ] Public-facing URLs return 200 from multiple geographic regions
- [ ] API endpoints return expected responses (not just 200 — validate response bodies)
- [ ] Error rate is at pre-migration baseline (check application logs, not just HTTP status)
Certificate verification:
- [ ] SSL certificate is valid on the new domain
- [ ] Certificate chain is complete (no intermediate certificate errors)
- [ ] Certificate expiry date is set correctly (not inheriting old cert expiry)
- [ ] Vigilmon SSL alerts are configured with 30-day threshold
Monitor reconfiguration:
- [ ] Monitoring interval reduced from migration-window 1-minute back to production interval
- [ ] Alert thresholds restored to production settings
- [ ] Source (old) infrastructure monitors updated or decommissioned
- [ ] Any migration-specific heartbeat monitors archived or repurposed
Rollback decommission:
- [ ] Old infrastructure kept available for rollback window (48–72 hours minimum)
- [ ] Source monitors watching old infrastructure remain active during rollback window
- [ ] Rollback procedure documented and team knows the trigger conditions
Vigilmon as Your Migration War Room Dashboard
During a migration window, your monitoring dashboard is your operational ground truth. Vigilmon's status page — visible to the whole migration team — shows the real-time health of every monitored endpoint simultaneously.
Pin the Vigilmon dashboard in your migration war room Slack channel or incident call. When the cutover happens, everyone on the call watches the same dashboard. The visual shift from source monitors healthy to target monitors healthy is your confirmation signal.
When something goes wrong, the monitors identify it before anyone on the call notices — giving you seconds to minutes of response time advantage over reactive debugging.
Conclusion
Uptime monitoring during cloud migrations isn't a passive observer — it's active operational infrastructure that gives you real-time confirmation of what's working and what's broken, a triggering mechanism for rollback decisions, and a timeline of events that makes post-migration review significantly easier.
Set up parallel monitoring before the migration window begins. Configure aggressive thresholds and redundant alerting. Define your rollback triggers based on specific monitoring signals before the pressure is on.
Set up migration monitoring with Vigilmon's free tier at vigilmon.online — multi-region checks, SSL monitoring, heartbeat monitoring, 1-minute intervals. No credit card required.
Tags: #cloudmigration #devops #monitoring #uptime #sre #infrastructure #aws #gcp #azure