How to Plan a Website Domain and DNS Migration

Direct answer：A systematic approach to inventorying DNS records, adjusting TTLs, managing certificates, and executing cutovers with monitoring and rollback procedures.

Prerequisites for DNS Migration

Begin by auditing all active DNS records across your current provider. Export zone files and categorize records by function (A, AAAA, MX, CNAME, TXT, etc.). Identify dependencies between services and external integrations.

Record Inventory Matrix

Create a migration tracking table with these fields:

Record Type：Hostname；Destination；TTL；Service Dependency；Verification Method

A：www；203.0.113.5；3600；CDN；curl -I verification

MX：@；mail.provider.com；14400；Email；SMTP test

TXT：_acme-challenge；"token"；300；SSL Cert；certbot validation

CNAME：api；gateway.loadbalancer.com；600；Microservices；Postman collection

AAAA：cdn；2001:db8::1；1800；Media delivery；Video load test

TXT：google-site-verification；"code"；86400；Search Console；GSC status check

Time-To-Live Adjustment Schedule

1. Baseline (7 days pre-cutover): Reduce TTLs to 300 seconds for critical records
2. Verification (72 hours pre-cutover): Confirm new TTLs propagate via dig +trace
3. Final (24 hours pre-cutover): Set all TTLs to minimum allowable values

Certificate and Authentication Planning

Map all SSL/TLS certificates to their corresponding services. Note expiration dates and validation methods (DNS or HTTP). For ACME challenges:

• Create pre-validated tokens for new DNS provider
• Schedule renewals to avoid overlapping validation windows
• Maintain parallel validation during transition

Acceptance Criteria:

• Zero certificate warnings in browser dev tools
• Qualys SSL Test scores ≥ A
• No mixed-content errors

Cutover Execution Protocol

1. Pre-flight (H3)

• Confirm backup of current zone files
• Disable automated DNS updates
• Notify dependent teams (security, DevOps, CRM)

1. Migration Window

• Import records to new provider with original TTLs
• Verify propagation with global DNS checkers
• Test each service through VPN tunnels from different regions

1. Post-cutover

• Monitor for 48 hours using synthetic transactions
• Maintain old DNS configuration for emergency rollback
• Update CDN origins and firewall whitelists

Exception Handling:

• When mail delivery fails, revert MX records immediately
• For search engine impacts, submit change of address in Search Console

Migration Planning Framework

Effective domain and DNS migration requires treating DNS as a dependency graph rather than individual records. This segment provides the working materials to execute the technical transition while maintaining service continuity.

Inputs and Pre-Migration Steps

1. DNS Inventory Template

• Record type (A, AAAA, CNAME, MX, TXT, etc.)
• Current value and priority (for MX/SRV)
• TTL value in seconds
• Service dependency (web, email, API, CDN, etc.)
• Verification method (dig, nslookup, curl test)
• Owner/team contact

1. TTL Reduction Schedule

• Lower TTLs to 300 seconds at least 48 hours pre-cutover
• Verify propagation with dig +trace across major resolvers
• Document original values for post-migration restoration

1. Certificate Audit

• List all TLS certificates by domain and SANs
• Note issuance platform (Let’s Encrypt, enterprise CA, etc.)
• Validate ACME challenges can resolve post-migration

Cutover Execution

1. Staged Record Updates

• Update non-critical services first (analytics, third-party scripts)
• Implement MX records during low-traffic windows
• Web A/AAAA records as final step

1. Monitoring Matrix

Check Type：Tool/Method；Threshold；Owner

HTTPS validity：SSL Labs API；No chain breaks；Security

App functionality：Synthetic monitoring；<500ms latency；DevOps

1. Rollback Criteria

• DNS propagation fails >30 minutes post-cutover

Verification and Exceptions

• Geodiversity Check: Use RIPE Atlas probes to confirm global resolution
• CDN Edge Cases: Purge cache and test origin binding
• Legacy Systems: Identify hardcoded IP dependencies before cutover

Acceptance requires 48 hours of monitoring with all systems meeting SLA thresholds. Document any variance as technical debt for future migrations.

Prerequisites for DNS Migration

Before initiating a domain or DNS migration, assemble these verified inputs:

• Current DNS Zone File: Export all active records from your provider
• Certificate Inventory: List all active TLS certificates with issuance dates and SANs
• Mail Configuration: Document MX records, SPF/DKIM/DMARC settings
• Verification Files: Crawl root domains for search console/analytics validation files
• Traffic Baselines: Capture 14-day metrics for DNS query volumes and response times

Record Prioritization Matrix

Classify each record by these criteria:

1. Critical Services: Records that would cause outages if misconfigured (e.g., A/AAAA for primary domains, MX)
2. Business Continuity: Records supporting revenue or operations (e.g., payment API endpoints)
3. Third-Party Dependencies: External services using your DNS (e.g., CDN CNAMEs)
4. Monitoring Only: Non-essential records (e.g., TXT for legacy verification)

Migration Execution Steps

Phase 1: Pre-Cutover Preparation

1. Reduce TTLs: Set all critical records to 300s at least 48 hours pre-migration
2. Parallel Testing: Configure new DNS servers with test subdomains first
3. Certificate Validation: Ensure new servers pass SSL checks for all SANs
4. Mail Flow Tests: Verify DKIM signatures pass on test messages

Acceptance Criteria:

• Test domains resolve correctly from multiple GEO locations
• SSL Labs shows A ratings for all certificates
• Mail-tester.com scores ≥ 8/10 for test messages

Phase 2: Controlled Cutover

1. Change Windows: Schedule during historically low-traffic periods
2. Staged Rollout: Migrate non-critical records first, then core services
3. Monitoring Setup: Configure alerts for:

• HTTP 5xx errors on migrated services
• SMTP queue growth

Exception Handling:

• If mail delivery fails, temporarily lower MX priority on old records

Post-Migration Verification

• DNS Consistency: Use dig +trace to confirm global resolution
• Certificate Chain: Validate intermediates with OpenSSL
• Backlinks: Check referrer logs for updated domains

Rollback Triggers:

• >30 minute outage for critical services
• Data inconsistency in replicated systems
• Authentication failures across multiple services

Migration Planning Framework

DNS Record Inventory

Create a migration spreadsheet with these fields:

1. Record Type (A, CNAME, MX, TXT, etc.)
2. Current Value (exact destination or priority)
3. TTL (current time-to-live in seconds)
4. Service Dependency (email, auth, payments)
5. Verification Method (dig, nslookup, curl test)
6. Acceptance Criteria (expected response pattern)

*Exception*: MX records require parallel testing with a secondary mail server before cutover.

Pre-Migration Steps

1. Reduce TTLs to 300 seconds for all A/CNAME records 72 hours pre-cutover
2. Export all zone files with timestamps
3. Document DNSSEC keys if enabled
4. Confirm certificate SAN fields cover both old and new domains

*Verification Item*: Test SSL handshake on new infrastructure using OpenSSL before DNS changes.

Cutover Monitoring Matrix

Check：Tool；Frequency；Threshold

TLS validity：SSL labs scan；15 min；No errors

Mail flow：SMTP test inbox；30 min；<5 min latency

*Exit Criteria*: All systems nominal for 4 hours with zero rollback triggers.

Ownership and Handoff Protocol

Business Responsibility Matrix

Field：Owner；Handoff Criteria；Escalation Trigger

Downtime SLA：Product Manager；Signed change request with approved impact window；Unplanned outage exceeds 15 minutes

Brand Continuity：Marketing Lead；Redirect mapping confirmed in CMS；Broken vanity URL detected

Billing Alignment：Finance Team；Registrar transfer lock disabled；Unauthorized domain charge

Technical Validation Steps

1. DNS Inventory Audit

Export all active records from current provider. Flag records requiring special handling:

• Email (MX, SPF, DKIM)
• Third-party service verifications (TXT)
• Legacy applications using hardcoded IPs (A/AAAA)

1. TTL Optimization Window

Reduce TTLs to 300 seconds at least 48 hours pre-cutover. Document original values for rollback. Exception: CDNs with contractual minimum TTLs.

1. Certificate Pre-Staging

Generate new certificates for the destination environment using the same CSR to maintain public key continuity. Verification item: OCSP stapling compatibility.

Acceptance Protocol

Checklist Item：Verification Method；Owner

DNS Propagation：Query all public resolvers in target regions；Network Engineer

SMTP Continuity：Send test messages to major providers；DevOps

HTTPS Integrity：Qualys SSL Test score ≥ A；Security Team

Rollback Criteria:

• Core business process disruption exceeding SLA
• Unresolved DNSSEC validation errors after 30 minutes

Migration planning framework

1. Pre-migration inventory

Create a DNS record matrix with these required fields:

Record Type：Current Value；Destination Value；Owner Team；TTL (seconds)；Dependency；Verification Method

A/AAAA：203.0.113.45；198.51.100.67；Networking；3600；CDN；dig +short @8.8.8.8

MX：mail.provider.com；mail.newprovider.com；Email；14400；SPF/DKIM；telnet mail.newprovider.com 25

TXT："v=spf1 …"；"v=spf1 …"；Security；300；Email flow；spf-tools.perplexity.ai

CNAME：www；lb.newcdn.net；WebOps；600；Analytics；curl -I https://www.www.shmlang.com

Verification criteria:

• All production records accounted for (missing records trigger stop decision)
• No test/staging records marked for migration (exception: QA validation required)
• TTLs reduced below 4 hours for critical records (observation: legacy systems may enforce higher minimums)

2. Certificate and authentication mapping

For each HTTPS service:

1. Confirm certificate SANs cover new domains
2. Document validation method (DNS-01 challenge preferred for wildcards)
3. Pre-stage ACME challenges if using Let’s Encrypt

Stop condition: Any certificate expiring within 30 days requires renewal before migration.

3. Cutover sequencing

Execute in this order with verification between steps:

1. Non-essential services (status.www.shmlang.com)
2. Secondary mail handlers (smtp2.www.shmlang.com)
3. Primary web assets (www.www.shmlang.com)
4. Core authentication (sso.www.shmlang.com)
5. Payment endpoints (api.payments.www.shmlang.com)

Acceptance checks:

• [ ] Zero 5xx errors in 15-minute monitoring window
• [ ] DNS propagation confirmed in 3 global regions (use dnschecker.org)
• [ ] All synthetic transactions passing (Selenium/Puppeteer scripts)

4. Rollback protocol

Maintain until 48 hours post-cutover:

1. Original DNS records at reduced TTL
2. Legacy certificate validity
3. Dual-endpoint monitoring

Exception handling:

• Email delivery failures: Revert MX records immediately
• Payment processing errors: Redirect API traffic at load balancer
• SEO impact: 301 redirects from old to new URLs

Implementation record

{

"migration_wave": 1,

"planned_start": "2024-03-15T22:00:00Z",

"systems_impacted": ["customer_portal", "marketing_site"],

"dns_records_modified": 14,

"ttl_adjusted": true,

"certificates_validated": true,

"monitoring_configured": true,

"rollback_test_performed": false,

"owner": "[email protected]",

"signoff": ""

}

Verification items:

• [ ] Confirm CDN cache purge capability
• [ ] Test email forwarding rules
• [ ] Validate analytics beacon endpoints

Related reading

• GEO optimization guides
• What GEO optimization means
• End-to-end GEO workflow
• GEO visibility solution

References

• Google: Creating helpful, reliable, people-first content
• Google: AI features and your website
• Google: Guidance on generative AI content
• 2026 critical survey of GEO research