The moment a site changes address is the only part of a migration the organization actually experiences. Everything before it is preparation and everything after is stabilization, but the cutover is what gets remembered.
Two ideas make it survivable. A cutover is a sequence rather than an event, and rollback stays available until acceptance is confirmed rather than until the traffic switches.
The sequence
- Initial synchronization. Copy the database and files to the target, days or weeks ahead. Slow, unglamorous, and best discovered to be slow well before the night.
- Validate the target. The site runs, the release is correct, integrations authenticate, the environment matches its definitions.
- Test. Functional, security and performance, against the acceptance criteria for this class of site.
- Incremental synchronization. Bring across what changed since the initial copy, and rehearse this step, because it is the one that behaves unexpectedly.
- Content freeze, if genuinely needed. Announced, time boxed and enforced rather than requested.
- Final synchronization. The last delta, with the source quiet.
- Traffic switch. The moment itself, and the shortest step in the list.
- Smoke tests. Automated, immediate, against the live address.
- Acceptance. A named person confirms, against written criteria.
- Continue or roll back. A decision, taken deliberately, within a window agreed in advance.
Steps four and six carry most of the risk, and step nine is the one most often skipped in favor of a general feeling that things seem fine.
Why Drupal rollback is not a redeploy
In a stateless application, rolling back means deploying the previous artifact. Drupal is not stateless, and three things make going back harder than going forward.
Database updates are frequently not reversible. Drush documents its deploy command as performing database updates and then configuration import. Those updates change schema and data. There is no general mechanism to undo them, and a module author is under no obligation to provide one. Redeploying the old code against an updated database gives you a site that will not run.
Content is created after the switch. The moment the new site is live, editors and visitors start producing data that exists nowhere else. Rolling back to the old system discards it unless something has been arranged, and by the time anybody notices, the data is a day old and belongs to somebody.
Caches and search indexes are downstream. Rolling the application back leaves derived state describing a site that no longer exists.
None of this makes rollback impossible. It makes rollback a designed capability rather than an assumed one.
The three honest rollback options
Pick one per class of site, in advance, and write it down. All three are legitimate; not choosing is not.
Restore to a known point. Return to a snapshot taken immediately before the final synchronization. Simple and correct, and it discards anything created since. Acceptable when the window is short and the site is not transactional.
Reverse the switch, and reconcile. Point traffic back at the source, then reconcile the content created in the meantime. This is only real if the reconciliation has been rehearsed. An unrehearsed reconciliation is a plan to write software during an incident.
Forward fix only. Declare that this class cannot be rolled back after the switch, and compensate with a heavier gate before it: deeper testing, a longer rehearsal, more people available. This is the honest choice for complex integrated sites, and stating it plainly is better than maintaining a rollback plan nobody believes.
The window, and who decides
Rollback stays available until acceptance is confirmed. That means three things have to be agreed before the night.
- How long the window is. Long enough to see real traffic, short enough that the reconciliation stays feasible. Frequently a business day rather than an hour.
- What triggers the decision. Written criteria, not a judgment in a call: error rate above a threshold, a failing journey, an integration down, data loss suspected.
- Who decides. One named person, available for the whole window, with the authority to say go back. Not a committee, and not whoever is still awake.
Agreeing this in advance is what stops the classic outcome: three hours of debate while the site is degraded, ending with the rollback window having quietly closed.
DNS, which is where the surprises live
The traffic switch is usually a DNS change, and DNS is not instant.
- Lower the time to live days ahead, not on the day. A record with a long TTL cached widely is a rollback that takes hours to take effect.
- Confirm propagation rather than assuming it. Check from more than one place and more than one resolver.
- Expect a period where both are live. Some visitors reach the old site after the switch. If both accept writes during that period, you have created a reconciliation problem. Making the source read only at the freeze is what avoids it.
- Certificates first. The target must already serve the correct certificate for the real hostname before the switch, not after.
The both-are-live period is the single most common source of migration data loss, and it is entirely avoidable by making the old site read only.
The freeze
A content freeze is a communications exercise with a technical enforcement mechanism, and organizations routinely do the first half only.
Announce it with enough notice to matter, time box it, and enforce it technically. Drupal's maintenance mode, or a read only arrangement on the source, is what turns a request into a fact. A freeze that is announced but not enforced produces exactly the content that will be lost.
Some sites cannot freeze at all. That is a legitimate constraint and it changes the design: it pushes you toward the reverse-and-reconcile option, or toward a shorter window with a rehearsed delta sync, and it should be identified during classification rather than during the cutover call. That classification is described in the Drupal site complexity assessment.
Rehearse the whole sequence
The single highest value practice here, and the one most often cut for time.
Run the entire sequence against a non-production target, end to end, including the incremental synchronization and including a rollback. Do it more than once. A migration that has been rehearsed five times is a different risk from one being performed for the first time at ten at night.
This is also the argument for building the migration as a pipeline rather than as a runbook of manual steps. A pipeline can be run repeatedly and identically, which is what makes rehearsal cheap enough to actually happen. The shape of that pipeline is in Azure DevOps for enterprise Drupal, and the wider method is the migration factory approach.
The integrations nobody switched over
A category of cutover failure that has nothing to do with the site itself. The application moves, and the things that talk to it do not know.
Outbound integrations usually behave, because they are configured in the site and travel with it. Inbound integrations are the problem: something external is calling your site on a schedule, authenticating in a way that was arranged years ago, and will keep calling the old address.
Four failure modes recur, and all four are silent for a while.
- Address based authentication. A partner allows requests from your old egress address. After the move the calls come from a new one and are refused. Nothing on your side errors, because the request never arrives.
- Hard coded endpoints. A third party has your old hostname or address in a configuration nobody at your organization can edit. Changing it needs their change process, which has its own lead time.
- Certificates pinned or trusted specifically. A client that trusts a particular certificate will fail against the new one, and the error will be reported as your outage.
- Scheduled jobs with no owner. A nightly import that has run for four years, whose owner left, discovered on the fifth night after cutover when a report is empty.
The mitigation is unglamorous and it is done during discovery rather than during cutover: list every inbound integration, find its owner, and give each one a lead time and a named contact. Then, during the freeze, watch the old system's logs. Traffic still arriving there after the switch is the list of integrations that did not get the message, and it is far better to learn that from a log than from the party at the other end.
Where an integration cannot be moved in time, keeping the old address answering as a redirect or a proxy for a defined period is a legitimate arrangement. It should be a decision with an end date, not an accident that persists for a year.
What to have ready on the night
- The written acceptance criteria for this site, and the person who will apply them.
- The rollback option chosen for this class, and the trigger conditions.
- A verified backup taken immediately before the final synchronization, and confirmation it restores.
- The automated smoke suite, run once against staging that day so you know it works.
- Monitoring already collecting, so the first hour has a baseline to compare against. That is observability.
- A communications plan for editors and for whoever answers the phone.
The backup point deserves emphasis. A backup taken before the cutover and never test restored is the most common single point of failure in a migration plan, and it is discussed at length in backup and disaster recovery.
Afterwards
Acceptance is not the end. Watch the site through a full traffic cycle, a scheduled job run and, where relevant, a month end. Keep the source system available and read only until the rollback window has genuinely closed, then decommission it deliberately rather than leaving it running for a year because nobody wanted to be the one to switch it off.
Cutover is one phase of Drupal migration and modernization services, and it is the phase where preparation is repaid or its absence is discovered. If you would like a review of a cutover plan before it runs, that is time well spent.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.