Infrastructure migrations are the moments of highest availability risk in the lifecycle of a SaaS product. Database cutovers, DNS propagation windows, load balancer changes, and certificate reissues all create opportunities for brief or extended outages — and the consequences land squarely on your customers.
A well-instrumented migration is fundamentally different from a poorly monitored one. This guide covers how to use uptime monitoring as a control layer during infrastructure migrations: what to monitor, when to monitor it, how to respond if something goes wrong, and how to confirm the migration succeeded after the dust settles.
Why Migrations Are the Highest-Risk Moments for SaaS Availability
Database Cutover Windows
Moving a live database — whether that is a PostgreSQL migration to a new provider, a MySQL upgrade to a new version, or a full data platform migration — requires a window in which the old database is finishing writes while the new one is being promoted. This window is the single most dangerous moment in most migrations.
Even with a well-planned cutover strategy (blue-green, read replica promotion, or dual-write), there is a brief period in which write operations may fail, queries may be slower than baseline, or connection pool exhaustion can cascade into application errors. Monitoring your application's health check endpoint with 1-minute intervals during this window is the minimum viable safety net.
DNS Propagation
DNS changes propagate across resolvers on their own schedule — typically within minutes for low-TTL records, but sometimes up to 48 hours for resolvers that ignore TTL aggressively. During this propagation window, some users will resolve to the old IP, some to the new one, and some may flip between them.
For a SaaS product, this means a portion of your users may experience connection errors, TLS certificate mismatches, or slow responses during a migration window that feels complete from your own network's perspective.
Monitoring from multiple geographic regions — as Vigilmon's consensus checking does — exposes this asymmetry. If probes in one region are returning 200 but probes in another are timing out, you are seeing live DNS propagation failure, not a complete migration success.
Load Balancer Changes
Swapping load balancer configuration — adding new backend instances, changing health check parameters, updating TLS policies — can produce brief windows of degraded availability. Health checks may fail for instances that have not yet warmed up. TCP connection draining may leave some in-flight requests in an ambiguous state.
These failures are often transient (5–30 seconds) but can look worse than they are without monitoring confirmation.
Certificate Reissues and Domain Changes
Migrating to a new domain, adding a subdomain, or reissuing SSL certificates creates a window in which certificate validation may fail for some clients. Certificate errors are particularly damaging in browser contexts: they generate hard errors, not graceful degradation, and some security-focused clients will refuse to connect even briefly after a certificate warning.
How to Use Vigilmon During a Migration
Monitor Both Old and New Endpoints Simultaneously
The most important migration monitoring pattern is dual monitoring: before cutting over, add monitors for both your old and new endpoints. This lets you verify the new environment is healthy before completing the cutover, and confirm the old environment is still stable during any parallel-running window.
In Vigilmon:
- Add monitors for all production endpoints in their current configuration
- As new infrastructure is staged, add monitors for the new endpoints (new domain, new load balancer IP, new health check URL)
- Verify the new endpoint monitors are green before initiating cutover
- Leave old endpoint monitors running for 24–48 hours after cutover to confirm no traffic is still routing to old infrastructure
Set More Aggressive Check Intervals
Standard monitoring at 5-minute intervals means a 20-minute outage could go undetected for up to 5 minutes. During a migration window, change your check interval to 1 minute for all affected endpoints.
Vigilmon's 1-minute check interval, combined with multi-region consensus, means you will know within 2–3 minutes whether a migration step has introduced an availability problem — rather than discovering it 15 minutes later when customers have already filed support tickets.
Tighten Response Time Thresholds
Migrations often degrade performance before they degrade availability. A database cutover might leave the new database handling queries significantly slower than baseline for several minutes while caches warm up. A load balancer change might briefly route traffic to cold instances.
Set response time alert thresholds to 150% of your normal baseline during the migration window. If your endpoint typically responds in 300ms, alert at 450ms. This catches performance degradation before it cascades into full availability loss.
Use Heartbeat Monitors to Confirm Cron Job Migration
Scheduled jobs and cron tasks are frequently missed during infrastructure migrations. Application servers get migrated; the cron infrastructure running on those servers does not always come with it.
Before migration, enumerate all scheduled jobs and their expected execution frequency. Add a heartbeat monitor for each one in Vigilmon. If the job POSTs to its heartbeat URL after each successful run, a missed heartbeat tells you the job did not run on the new infrastructure — without waiting for a customer to notice missing data or a failed report.
Common jobs to heartbeat-monitor during migrations:
- Database backup jobs
- Billing and invoice generation
- Email digest sends
- Data sync and ETL jobs
- Report generation jobs
- Cache warming jobs
SSL Certificate Monitoring During Domain Changes
When migrating to a new domain or reissuing certificates, add a dedicated SSL certificate monitor for the new domain before completing the cutover. Verify:
- Certificate is issued and valid
- Certificate covers all required subdomains (wildcard or SANs)
- Certificate chain is complete (no intermediate certificate missing)
- Certificate expiry gives you sufficient lead time (add an alert at 30 days before expiry)
A certificate that validates correctly from your local network may still fail for users if the intermediate certificate is not served correctly. Vigilmon's external probes test from the same perspective as your users — not from your internal network — catching these issues before they affect production traffic.
Incident Response During Migration Windows
Pre-plan your rollback path before the migration starts. An incident during a migration window with no pre-planned rollback is the worst possible scenario: pressure to fix forward on a half-migrated system, unclear state, and customer impact accumulating.
Rollback Decision Criteria
Define your rollback triggers before the migration:
- Alert fires within 5 minutes of cutover → immediate rollback
- Response time degrades more than 50% above baseline for more than 10 minutes → evaluate rollback
- Error rate above 1% for more than 5 minutes → immediate rollback
- Any heartbeat monitor missed for more than 2 intervals → investigate, prepare rollback
Communication During an Active Migration Incident
- Post to your internal incident channel immediately when an alert fires
- Confirm the scope: is it affecting all users or a subset? (Multi-region monitoring data answers this)
- If rollback is triggered, post a customer status update within 5 minutes
- Update your status page throughout the incident
Post-Migration Verification Checklist
After a migration is complete, do not assume success because monitors are green. Run a systematic verification:
Endpoint verification:
- [ ] All HTTP/HTTPS monitors returning 200 with expected response content
- [ ] All TCP monitors returning connection success
- [ ] Response times within 10% of pre-migration baseline
Certificate verification:
- [ ] SSL certificate valid and serving correct domain(s)
- [ ] Certificate chain complete
- [ ] Expiry date confirms new certificate (not cached old certificate)
DNS verification:
- [ ] DNS records resolving to new infrastructure from multiple geographic locations
- [ ] Old DNS records removed or updated (prevent split-brain after TTL expires)
- [ ] Any CNAME, MX, or SPF records updated as required
Scheduled job verification:
- [ ] All heartbeat monitors received at least one ping within expected interval
- [ ] Review logs for any jobs that ran but encountered errors
- [ ] Confirm backup jobs ran on new infrastructure
Traffic verification:
- [ ] Verify no traffic still routing to old infrastructure after 24 hours
- [ ] Remove old endpoint monitors from Vigilmon if old infrastructure is decommissioned
Migration Monitoring Configuration Summary
A Vigilmon configuration for a SaaS migration looks like this:
- Before migration: Add monitors for new endpoints in staging at 1-minute intervals
- Migration day: Switch all monitors to 1-minute intervals; add heartbeat monitors for scheduled jobs
- During cutover: Watch multi-region consensus — a partial failure is visible as geographic asymmetry
- Immediately after: Verify all monitors green for 30+ minutes before decommissioning old infrastructure
- 24–48 hours after: Confirm old infrastructure monitors are dark; decommission and clean up
Conclusion
Infrastructure migrations are unavoidable as SaaS products grow. The difference between a migration that goes smoothly and one that generates a customer-impacting incident often comes down to the monitoring in place during the cutover window.
Dual monitoring of old and new endpoints, aggressive check intervals, response time thresholds calibrated to catch degradation before availability loss, and heartbeat monitors for every scheduled job form a comprehensive monitoring strategy for migrations. Multi-region consensus checks expose geographic propagation asymmetry that single-probe monitoring cannot detect.
Set up migration monitoring at vigilmon.online — free tier covers the basics, and setup takes under 5 minutes before your next migration window opens.
Tags: #monitoring #migration #devops #saas #infrastructure #uptime #sre