How to Migrate a Drupal Site
with Zero Downtime

Every Drupal migration eventually faces the same question: how do we cut over to the new site without taking it offline? For sites that serve citizens 24/7, handle transactions, or have SLA commitments, the answer has to be zero downtime — or as close to it as operationally achievable.

This post walks through the full operational approach we use: from pre-migration planning through DNS cutover and post-launch verification. It's drawn from real migrations, including a 40,000-node government platform we delivered with a 22-minute planned maintenance window.

Why downtime matters more than most teams think

Beyond user impact, unplanned downtime during a migration creates cascading problems: Google crawls a broken site and downgrades rankings, CDN caches serve stale content, monitoring alerts flood the team during the most stressful moment of the project, and new content created in the old system after the cutover point gets lost.

The goal of zero-downtime migration is not just user experience — it's operational safety. Every minute of ambiguity about which system is the source of truth creates risk.

Pre-migration: the audit and risk register

Zero downtime starts weeks before launch day. The technical audit should produce a risk register with every item that could delay or complicate cutover ranked by severity and likelihood:

• Data quality issues — malformed content, deprecated field types, orphaned entities that will fail migration scripts
• Custom module dependencies — modules that have no Drupal 10 equivalent and require custom replacement
• Third-party integrations — external systems that need to switch endpoints simultaneously with the cutover
• DNS TTL — if your current TTL is 24 hours and you don't lower it a week before launch, you'll have a slow, unpredictable cutover
• SSL certificate validity — ensure the new environment's certificate is valid before cutover, not during
• Cache warm-up time — a cold Drupal cache on a complex site can create significant load on first access

Environment parity: staging must be production

The most common cause of launch-day surprises is a staging environment that doesn't match production. Staging must have the same PHP version, the same server configuration, the same caching layer (Redis, Varnish), and the same CDN settings as production.

Run a full load test against staging before you ever start the migration sequence. If performance is acceptable on staging under realistic load, you have evidence that production will behave the same way. If you skip this step, launch day becomes a live performance test.

The migration sequence

The sequence matters. Running these steps in the wrong order creates data loss or integrity problems:

1. Configuration migration — content types, fields, views, permissions. This is the foundation everything else depends on.
2. User migration — accounts and roles, before content so author references resolve correctly.
3. File migration — managed files and public assets, before the nodes that reference them.
4. Content migration — nodes, taxonomy terms, paragraphs — in dependency order.
5. Relationship verification — automated checks confirming entity reference counts match source.
6. Final delta sync — content created or modified in the source system after the main migration run.

Blue/green deployment strategy

In a blue/green deployment, the new Drupal 10 environment (green) runs in parallel with the existing Drupal 7 site (blue) until cutover. Traffic continues hitting blue while green is built, tested, and loaded.

Cutover then becomes a load balancer change rather than a server migration — instant and reversible. If anything goes wrong in the first minutes after cutover, you flip the load balancer back to blue. This rollback capability is the most important safety property of blue/green.

Database sync for near-zero content delta

The migration run that builds the new database happens days or weeks before launch. Between then and cutover, editors keep creating content in the old system. The delta sync handles this gap:

• Run the main migration against a full database clone 3–5 days before launch
• Run incremental delta migrations daily against updated source data, reducing the sync time needed at launch
• On launch day, do a final sync of only content modified in the last 24 hours — this should take minutes, not hours
• Immediately before cutover, put the source system into read-only mode (or maintenance mode) to freeze the delta

DNS cutover: TTL, timing, and rollback

Lower your DNS TTL to 60–300 seconds at least one week before launch. At launch TTL, the propagation window shrinks from hours to minutes, making the cutover and any potential rollback much faster.

Schedule the cutover during your lowest-traffic window — typically between 11pm and 5am. Execute the following sequence:

1. Enable maintenance mode on the source system
2. Run the final delta migration
3. Verify content counts and spot-check critical pages on the new environment
4. Update DNS to point to the new environment
5. Monitor error rates and response times for 30 minutes
6. Disable maintenance mode on the new environment
7. Keep the old environment live and accessible internally for 48 hours as a rollback option

Post-launch verification checklist

• Cache warm-up: crawl critical paths with a tool like Screaming Frog to pre-populate Varnish/Redis
• Verify all 301 redirects from old URLs are resolving correctly
• Check Google Search Console for crawl errors within 24 hours of launch
• Confirm all third-party integrations (CRM, analytics, forms) are firing correctly in production
• Run a Lighthouse performance baseline to compare against pre-launch benchmarks
• Monitor error logs for the first 48 hours — catch regressions before users report them