Migrating at Scale: Moving 20+ Sites to a New Host Without Chaos

Moving a single website is rarely stress-free, yet shifting an entire portfolio of twenty or more sites magnifies every risk. One mistimed DNS switch can take dozens of brands offline, and a missed redirect could drain months of organic traffic. Contracts, client SLAs and revenue targets depend on a smooth handover.

A disciplined approach, inventory first, phased cutover, well-documented runbooks and rehearsed rollback, turns that potential chaos into a predictable programme. Follow the framework below, and you will know exactly what to move, when to move it and how to prove success.

Common Risks and What Users Are Looking for

Business owners and developers researching “bulk migration” typically face four pressing concerns:

• Minimise downtime and protect SEO rankings during and after cutover
• Avoid broken links, email interruption and data loss that erode customer trust
• Coordinate multiple teams and sites without chaos, ensuring clear ownership at every step
• Guarantee rollback clarity, knowing precisely when and how to revert if smoke tests fail

Planning: Inventory, Dependencies and Success Criteria

Planning sets the tone for the entire migration. Capture every asset, relationship and expectation before touching DNS.

Create a Complete Inventory

Catalogue each site’s:

• Domain name and registrar
• Hosting account and control panel access
• CMS and plug-in versions
• SSL certificate status
• DNS provider and current TTL
• Databases, file stores and cron jobs
• Email services and MX records
• Third-party integrations such as payment gateways, CDNs and analytics
  (Add internal guide links where available: [Link to DNS management guide], [Link to SSL renewal guide]).

Map Dependencies and Owners

Tag every site with:

• Business owner and technical owner
• SLA or contractual uptime requirement
• Uptime sensitivity (e.g., eCommerce checkout vs campaign microsite)
• SEO-critical pages and keyword rankings
• External IP allowlists, APIs or webhooks that must be updated

Define Success Criteria and KPIs

Agree on measurable thresholds before migration:

• Downtime window: Maximum minutes of 503 responses permitted.
• Error-rate threshold: Acceptable 4xx/5xx percentage during stabilisation.
• Rollback triggers: Predefined conditions that force a revert.
• SEO checkpoint: No unexpected 404s, correct canonicals and indexed pages verified in Search Console.

Choosing a Strategy: Phased Cutover vs Big Bang

Strategy determines both risk and speed. Two patterns dominate large-scale moves.

1. Phased Cutover

A phased cutover migrates sites in controlled waves, often staging low-risk, informational sites first, then high-traffic properties.

Pros

• Limits blast radius and simplifies rollback per wave
• Provides real-time learnings for subsequent batches
• Enables SEO monitoring on a subset before wider roll-out

Cons

• Longer coexistence between old and new hosts increases operational complexity
• DNS rules can grow messy when both environments must resolve simultaneously

2. Big Bang

A single maintenance window flips every site once.

When it works

• Homogeneous stack with automated deployment and proven backups
• Organisation can withstand a clearly defined outage or a late-night cutover window

Risks

• All-or-nothing rollback increases pressure
• SEO and availability exposure spike if anything is missed
• Although coexistence costs fall, preparation overhead rises

Pre-Migration Checklist: The Practical Migration Checklist

Use this actionable migration checklist to eliminate surprises. Assign an owner to each step.

• Backups: Capture full site, database and media files; perform a restore test. [Link to backup runbook]
• Staging parity: Ensure staging mirrors production software versions and extensions.
• SSL certificates: Generate certificates for the new host; keep overlap to prevent expiry gaps.
• DNS TTL strategy: Lower TTL (e.g., to 300 s) 48 hours before cutover so changes propagate quickly.
• IP allowlisting: Register new host IPs with payment providers or CRMs ahead of time.
• Data sync plan: Choose real-time replication, incremental rsync or final dump + apply deltas.
• Media and file stores: Confirm central object storage or migrate assets via CDN rewrite rules.
• Emails: Map MX records; test inbound and outbound messages on staging.
• Monitoring and alerting: Activate uptime and error monitoring on both environments pre-cutover.
• SEO-safe prep: Maintain canonical tags, 301 redirect maps, robots rules and refreshed XML sitemaps.
• Stakeholder comms: Schedule maintenance notifications and on-call rotas per wave.

Technical Execution: Runbooks, Automation and DNS Cutover

Execution converts planning into a deterministic sequence that engineers can follow under pressure.

Build a Site-Specific Runbook Template

Every site gets its own runbook containing:

• Pre-cutover checklist reference
• Precise DNS records to change
• Step-by-step rollback instructions
• Smoke tests and expected outputs
• Contact list and escalation matrix

Store runbooks in a shared version-controlled repository for single-source-of-truth assurance.

Data Migration and Synchronisation Strategies

Choose techniques based on database size and write frequency:

• Live replication keeps old and new databases in sync until the final switch.
• Transactional queueing captures writes during the freeze window and replays them to the new host.
• Incremental sync uses rsync or binary logs, followed by a brief maintenance window for the last delta.

Always validate row counts and checksums before and after migration to catch silent corruption.

Automation and CI/CD

Automate repetitive steps:

• Infrastructure-as-Code for DNS and server provisioning
• Scripted SSL issuance via Let’s Encrypt ACME
• Deployment pipelines per site that promote builds from staging to production

Manual verification remains essential for business-critical transactions and third-party callbacks.

DNS Management and Phased Cutover Steps

Standard flow:

1. Lower TTL during the planning phase.
2. Perform final data sync.
3. Update A/CNAME records to the new host.
4. Monitor propagation and error logs.
5. Restore original TTL once stable.

Smoke Tests and Acceptance Criteria

Immediately after cutover:

• Home and checkout pages load in < 2 s.
• Forms submit, and emails trigger.
• Third-party integrations (payments, analytics) succeed.
• SSL chain valid; no mixed-content warnings.
• Error logs show zero critical events.

Curl example: curl -I -k https://example.com | grep “HTTP/” should return 200 OK.

Pilot, Testing and Rollback Plan

A small-scale pilot validates assumptions with minimal blast radius.

Run a Small Pilot

Select a low-risk but representative site group. Execute the full runbook, push live traffic through for several hours, and track KPIs (uptime, error rates, response times). Document lessons learned and refine templates before the next wave.

Rollback Triggers and Procedure

Define hard rollback triggers such as sustained 5 % error rate, payment failures or critical ranking drops. Revert by repointing DNS, restoring database snapshots and invalidating CDN caches. Keep the process scripted and rehearsed so a revert completes in minutes, not hours.

Post-Migration Governance, SEO and Monitoring

Stabilisation doesn’t end at cutover; governance protects the investment.

Post-Cutover Checks

Verify HTTP 200 responses on critical URLs, ensure canonical tags and 301 redirects work, submit updated sitemaps and confirm ownership in Google Search Console. Re-check SSL chains, MX records and webhook endpoints.

Ongoing Monitoring and Runbook Updates

Maintain heightened monitoring for 72 hours after each wave. Log any incidents, run post-mortems and update runbooks accordingly. Assign long-term ownership for DNS records, SSL renewals and key metrics.

Move Fast, Break Nothing

Large-scale host moves succeed when inventory drives prioritisation, phased cutover contains risk, and repeatable runbooks guide every action. Start with a pilot wave to validate tooling and smoke tests, then apply each lesson to the next batch until the final site flips without fuss.

Crazy Domains supports large-scale migrations with reliable Australian hosting, expert DNS and SSL management, bulk domain control, migration-ready infrastructure and local support that keeps multi-site transitions stable, secure, and predictable.

Planning a multi-site move? Migrate with confidence using Crazy Domains’ high-performance hosting and expert migration support. Get started today!