The instinct is to start with the destination. Pick a cloud, stand up a server, move a site, see how it goes. That works for one site and fails for an estate, because the thing that makes an estate migration succeed is built before the first site moves.
What follows is the order that tends to work, and the reasoning for each step. It assumes you have already decided to move; if that is still open, the comparison between a managed platform and infrastructure you control is the earlier conversation.
Step 1. Inventory what is actually there
Begin with a list, and expect it to be wrong. Every estate has sites nobody mentioned, environments nobody uses and integrations nobody documented.
For each site, record the Drupal version, the module set with custom code separated from contributed, the theme, database size, file volume, traffic shape, every integration and where it points, the authentication arrangement, whether search is internal or external, scheduled jobs, and who actually owns it.
Two items are easy to miss and expensive to discover late: outbound integrations, because the new network path may not permit them, and inbound integrations, because something is calling your site on a schedule and will not be told you moved.
The inventory is also where the first genuine finding usually appears, which is that some proportion of the estate should be retired rather than migrated. Migrating a site nobody has updated in four years is the most expensive way to discover it was not needed.
Step 2. Classify, and let the classification decide the plan
An inventory is a list. A classification is a decision aid. Score each site on version currency, custom code, data volume, integration count, authentication complexity, business criticality and technical debt, and you get a matrix that tells you which sites are alike.
That matrix drives five things that would otherwise be guesses: which sites make good pilots, what order to move in, how deep testing needs to be per class, which sites need a rehearsed rollback rather than a theoretical one, and what acceptance means. The method is in the Drupal site complexity assessment.
A pilot should be representative, not easy. A pilot chosen because it is simple proves that simple sites migrate, which nobody doubted.
Step 3. Decide what has to exist before anything moves
This is the step organizations compress, and compressing it is what turns a factory back into a series of projects.
The platform you are leaving does more than host. It provisions, deploys, manages environments, performs Drupal lifecycle operations, runs bulk actions, monitors, exposes self-service, backs up and restores, applies security tooling, and provides somebody to call. Each needs a named replacement. The full list is in what actually has to be rebuilt.
The practical test: write the list, put a name against every row, and refuse to start wave one until no row says "we will work that out". Rows that stay blank do not disappear. They reappear as an incident.
Step 4. Build the platform from code, and prove it
Declare the environment in Infrastructure as Code rather than building it by hand. HashiCorp describes Terraform as an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently, and the property you are buying is repeatability.
The proof is simple and frequently skipped: destroy a non-production environment and rebuild it from the definitions. If that works, you have a platform. If it does not, you have a server that happens to be running, and your disaster recovery plan is fictional.
One caution worth designing for early. Terraform must store state about your workspace's managed infrastructure and configuration, and HashiCorp is explicit that mishandling that state risks exposure of secrets stored in the state file. State is an asset with a custody problem. Decide where it lives and who can read it before the first apply, not after. See Terraform and Infrastructure as Code for Drupal.
Step 5. Build the pipeline, including the gates
Build the delivery pipeline before the volume arrives. A migration is the one moment when the delivery process is genuinely open for change, and gates added now cost a fraction of gates retrofitted later.
The pipeline must build an artifact once and promote that same artifact through every environment. If each stage rebuilds, the thing you tested is not the thing you shipped. It must also run the Drupal deployment sequence correctly afterwards: Drush documents its deploy command as performing database updates, configuration import, cache rebuild and deployment hooks, in that order.
Security gates belong here rather than in a later phase, for the reasons set out in building a Drupal DevSecOps pipeline in Azure DevOps.
Step 6. Move the pilot, and change the plan
The pilot's purpose is not to move a site. It is to find out what your plan got wrong while the cost of being wrong is still small.
Expect the pilot to surface at least three things nobody predicted. Typical candidates: a file path assumption baked into custom code, an integration that authenticated by source address, a scheduled job nobody owned, a caching behavior the old platform supplied invisibly, or a content editing workflow that depended on an interface that no longer exists.
If the pilot produces no surprises, be suspicious of the testing rather than pleased with the plan.
Step 7. Move in waves
Group sites so that each wave teaches the next, and treat the platform itself as wave zero. Low complexity first to build confidence and tooling, integration heavy sites once the patterns are proven, mission critical last.
How many waves, what goes in them and how long stabilization takes are properties of your estate rather than of a methodology. Any plan that arrives with the waves already decided has not looked at your inventory. The shape and the traps are in sequencing a large estate.
Step 8. Cut over so that you can go back
A cutover is a sequence, not an event: initial synchronization, validation of the target, functional and security and performance testing, incremental synchronization, a content freeze if one is genuinely needed, final synchronization, the traffic switch, smoke tests, acceptance.
One rule does not vary. Rollback stays available until acceptance is confirmed. That is harder than it sounds in a Drupal context, because database updates are frequently not reversible and content created after the switch does not exist in the old system. Designing for it is the subject of cutover and rollback strategy.
Decide the DNS behavior in advance too. Time to live values should be lowered days before the switch, not on the day, and somebody should confirm the change actually propagated rather than assuming it.
Step 9. Stabilize before you declare victory
A site that passes acceptance at eleven on a Tuesday has not yet met a real traffic peak, a scheduled job at month end, or a search index rebuild. Watch it under genuine load before the wave is closed.
This is also where observability stops being a deliverable and starts being useful. Drupal observability covers what to watch, and NIST supplies the two recovery objectives that should already be written down by this point: the recovery point objective as the point in time to which data must be recovered, and the recovery time objective in terms of the maximum amount of time a resource can remain unavailable.
Step 10. Hand over on purpose
The most common failure in these programs is not technical. It is that the platform is delivered and nobody owns it, so patching drifts, monitoring alerts to a mailbox nobody reads, and the restore is never rehearsed.
Name the operating model before go live: who patches, who watches, who responds, who improves it, and what the escalation path is at three in the morning. Whether that is internal, external or shared is a separate question from whether it exists. Enterprise Drupal managed services describes what it usually contains.
What to avoid
- Starting with the destination. The cloud is the easy decision. The inventory is the one that changes the plan.
- Migrating the estate you have without asking which parts should exist.
- Treating the pilot as a demonstration rather than an experiment.
- Deferring the security gates to a phase two that is never scheduled.
- Declaring success at the traffic switch rather than at acceptance.
LABUSA's enterprise Drupal modernization approach follows this order, and the honest starting point is nearly always the inventory. If you would like a second reading of yours, that is a good first conversation.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.