The most expensive assumption in a Drupal platform migration is that you are replacing hosting.
You are not. You are replacing a bundle of operational capabilities that happened to be sold together, most of which became invisible precisely because they worked. An organization that migrates the application and leaves the bundle behind arrives somewhere worse than where it started: the same Drupal, on infrastructure nobody has automated, with none of the scaffolding that used to be included.
This is the list. Ten rows. Each needs a name against it before wave one, and a row that says "we will work that out" does not disappear, it reappears as an incident.
1. Infrastructure provisioning
What the platform did: created an environment when you asked for one, with networking, compute, database, storage and certificates already arranged.
The replacement: Infrastructure as Code, held by the organization and applied through a pipeline rather than 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.
The test: destroy a non-production environment and rebuild it from the definitions. If it comes back, this row is done. See Terraform and Infrastructure as Code for Drupal.
2. Code deployment
What the platform did: took a branch and put it somewhere, following a workflow it defined.
The replacement: a pipeline that builds an immutable artifact once and promotes that same artifact through every environment. Microsoft describes Azure Pipelines as combining continuous integration, continuous testing and continuous delivery to deploy code projects to any destination.
The trap: a pipeline that rebuilds per stage. The artifact you tested is then not the artifact you shipped, and every security gate upstream became decorative.
3. Drupal lifecycle operations
What the platform did: ran the Drupal specific steps after a deploy, and offered cache clears, configuration imports and database updates as buttons.
The replacement: Drush, orchestrated. It describes itself as a command line shell and Unix scripting interface for Drupal, and its deploy command standardizes the sequence: database updates, then configuration import, then cache rebuild, then deployment hooks.
The trap: treating a Drupal deploy as a file copy. The order of that sequence is load bearing, and a pipeline that gets it wrong produces failures that look intermittent. See Drupal lifecycle automation.
4. Environment management
What the platform did: let a developer create a branch environment and throw it away afterwards.
The replacement: pipeline driven creation and teardown from the same definitions used for production, with environments modeled as objects rather than as strings in a script. Microsoft describes an environment as a group of resources you can target with deployments from a pipeline, and notes that deployment history can be used to identify the source of changes.
The trap: environments that exist forever because nothing tears them down. Cost grows and nobody can say which are in use.
5. Bulk operations across many sites
What the platform did: acted on the estate rather than on a site.
The replacement: a job runner with per site results. The properties that matter are idempotence, bounded concurrency, and a report naming which sites succeeded and which did not.
The trap: a loop inside a release pipeline. A bulk operation across forty sites will not fail cleanly; it will succeed on thirty-seven, and you need to know which three.
6. Monitoring
What the platform did: told you when the site was down, and sometimes when it was slow.
The replacement: cloud native metrics plus application signals, covering Drupal health, PHP, database, cache and load balancer behavior, with alerting that reaches a person.
The trap: infrastructure monitoring alone. Healthy servers and an unusable site is an ordinary combination. See Drupal observability.
7. Self-service
What the platform did: gave delivery teams a console where they could act without asking anyone.
The replacement: a catalog exposing approved actions, without granting infrastructure access.
The trap: replacing a console with a ticket queue. It works for a month and then the platform is perceived as slower than what it replaced, which is a fair judgment. See self-service platform operations.
8. Backup and recovery
What the platform did: took backups, and offered a restore button that somebody had presumably tested.
The replacement: automated backup covering the database, public files, private files, configuration and the environment definitions, with defined retention and a rehearsed restore.
The trap: assuming a backup is a control. NIST gives the two objectives that make it measurable: 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 time a resource can remain unavailable. See backup and disaster recovery.
9. Security
What the platform did: supplied a web application firewall, transport security, some access control and a degree of platform hardening, largely invisibly.
The replacement: identity, secrets management, edge protection, hardening, vulnerability scanning, centralized logging and a route into whatever the organization uses for security monitoring.
The trap: discovering during an audit that the platform's controls were the controls. See Drupal cloud security architecture.
10. Operations
What the platform did: answered the phone.
The replacement: a named operating model. Patching, watching, responding, improving, and an escalation path that works at three in the morning.
The trap: the row most often left blank, because it is the only one that cannot be delivered by a project. See enterprise Drupal managed services.
How to use this list
Print it. Put a name and a date against every row. Refuse to schedule wave one until none of them says "to be confirmed".
Two further disciplines make the exercise honest.
Rank by what happens if it is missing on day one. A missing self-service catalog is friction. A missing restore capability is an existential problem discovered at the worst moment. Sequence accordingly.
Distinguish built from bought. Some rows are naturally built once and reused; some are naturally purchased; and operations is naturally a service, internal or external. There is no prize for building all ten, and organizations that try tend to arrive with nine finished and the tenth unstaffed.
What you gain that was not in the bundle
The list above is framed as replacement, which understates the exercise. Several capabilities are not like for like, and the new versions are genuinely better than what they replace. It is worth saying so, because a business case built entirely on parity reads as an expensive way to stand still.
- Cost that resolves to a resource. A platform invoice is a number per site. An account you own attributes spend to a database, an environment or a storage bucket, which is what makes an efficiency conversation possible at all.
- Evidence in your own format. Logs, access records and configuration state land where your security function already looks, rather than in an interface it has to be given access to and taught to read.
- Architectural freedom. An integration that has to reach a system inside your network is a design decision rather than a support request with an uncertain answer.
- Consolidation. Drupal stops being a special case administered separately and becomes another workload under the same identity, monitoring, backup and recovery arrangements as everything else. That is a reduction in operational surface, not an addition.
- Environments that match production. Because both are produced from the same definitions, a difference in behavior points at the release rather than at the environment, which removes an entire category of unproductive debugging.
None of that arrives automatically. Each is a consequence of doing the ten rows deliberately rather than minimally, and each is worth naming in the business case, because otherwise the whole program is justified on a license line that a vendor can discount.
The three rows most often forgotten
From assessments of estates mid-migration, the same three go missing.
- Bulk operations. Nobody misses them until the first estate-wide security update, at which point the absence is felt sharply and immediately.
- Self-service. Reintroduced as a ticket queue, which quietly makes the new platform less usable than the one it replaced.
- Retirement. Not on this list because the platform rarely did it either, which is why estates only ever grow. Automating it is what turns retirement from an intention into a routine.
The replacement is a platform, not a product
No single tool replaces this bundle, and the vendors of individual tools are not claiming otherwise. Terraform provisions. A pipeline delivers. Drush operates Drupal. Monitoring watches. None of them answers a phone.
What replaces a managed Drupal platform is an integrated operating platform assembled deliberately, which is exactly the work described in replacing a managed Drupal platform. The sequence for getting there is in migrating Drupal off a proprietary hosting platform, and the delivery method is the migration factory approach.
If you are pricing this decision, the ten rows above are what the business case should cost, rather than the cloud resource bill. We are happy to work through them with you.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- Microsoft, What is Azure Pipelines?, Azure DevOps documentation
- Microsoft, Create and target an environment, Azure Pipelines documentation
- HashiCorp, What is Terraform?, Terraform documentation
- Drush, Drush 13 documentation
- Drush, Deploy command, Drush 13 documentation
- NIST, Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1