A managed Drupal platform's most valuable feature is rarely the hosting. It is that a developer can ask for an environment and receive one, or roll a release back, without anybody opening a terminal. Replacing that is not a hosting problem. It is an automation problem, and it is the one most often underestimated when an estate moves.
Drush is the tool that does the Drupal specific half. It describes itself as a command line shell and Unix scripting interface for Drupal. The rest is the orchestration around it.
The operations an estate actually repeats
Write the list down before automating anything, because the list is the requirement.
- Create a new site, with its database, storage, hostname, certificate and configuration.
- Clone an environment, usually production to staging, with data sanitized on the way.
- Deploy a release, including the ordered Drupal sequence that follows the file copy.
- Update Drupal core, contributed modules and PHP dependencies, across the estate rather than per site.
- Back up on a schedule, with retention, and restore on demand.
- Clear and warm caches without a person deciding which caches.
- Import configuration as part of a release rather than as a manual step.
- Run database updates in the right place in the sequence.
- Enter and leave maintenance predictably.
- Retire a site: archive the content, release the hostname, remove the resources, keep the evidence.
The last one is skipped almost universally, and it is the reason estates only ever grow. If retirement is not an automated operation with an owner, no site is ever retired, and the migration you are planning is larger than it needs to be.
The deploy sequence, and why its order is load bearing
Drush documents its deploy command as standardizing how Drupal deployments work. After the deployment script has updated the codebase on the target, the command performs database updates, then configuration import, then a cache rebuild, then deployment hooks.
That order is not a preference. Configuration import expects the schema the database updates just created. The cache rebuild expects the configuration that import just applied. Deployment hooks run last precisely because they can then assume both.
Three consequences for anyone building this.
- Do not parallelize the sequence. Failures then appear intermittent and get blamed on infrastructure.
- Decide what happens on partial failure. A successful database update followed by a failed configuration import leaves a site in a state that is neither release. The automation should say what to do, not exit non-zero and leave it.
- There is a window where code is new and the database is not. On a busy site users can see it. Whether that window is covered by maintenance mode is a design decision with a real trade-off, and it should be made rather than inherited.
Doing it across an estate rather than a site
Every operation above is straightforward for one site. The engineering is in doing it for forty, and four properties separate automation that scales from scripts that do not.
Idempotence. Running an operation twice must be safe. Somebody will re-run it, usually because the first run appeared to hang.
Partial failure is normal. A bulk update across forty sites will not fail cleanly or succeed cleanly. It will succeed on thirty-seven. The automation has to report which three, why, and let those three be retried without touching the others.
Reporting is the deliverable. A bulk operation whose output is a wall of console text is not usable evidence. What is needed is a per site result that someone can act on and file.
Concurrency is bounded. Forty simultaneous database updates against a shared database service is a self-inflicted incident.
The consequence for design is that estate operations belong in a job runner with per site results, not in a loop inside a per site release pipeline. The release pipeline releases one site well; the job runner acts on many.
Where the operations should be invoked from
Three layers, and confusing them causes trouble.
- The release pipeline performs the deploy sequence for one site as part of a release. This is where the artifact is promoted and where approvals live.
- Scheduled automation performs backups, dependency scans, drift detection and reporting without anyone asking.
- On-demand automation performs create, clone, restore and retire when a person asks for them, ideally through a catalog rather than a ticket. That is self-service platform operations.
All three call the same underlying operations. If they call different ones, they will drift, and the version invoked at three in the morning will be the least tested.
Updates, which are the real recurring cost
The unglamorous truth of running a Drupal estate is that most operational effort goes into keeping dependencies current, and that a managed platform absorbs a visible part of that.
A workable arrangement has four parts.
- Detection is automatic and scheduled. Something checks for available updates and for known vulnerabilities in the dependency tree on a cadence. OWASP describes Dependency-Check as a Software Composition Analysis tool suite that identifies project dependencies and checks whether any have known, publicly disclosed vulnerabilities, and running it on a schedule rather than only on commit is what catches an advisory published after your last release.
- Routine updates are proposed automatically. An update branch and a pull request per site, tested by the same pipeline as any other change.
- Security updates have a separate, faster path. With a pre-agreed decision about what may bypass the normal cadence and who authorizes it. That decision belongs to a person and should exist before it is needed.
- Coverage is reported. Somebody should be able to answer, on any given day, which sites in the estate are behind and by how much. Without that number, patching becomes a matter of belief.
Composer is what makes this tractable: it describes itself as a tool for dependency management in PHP, and is explicit that it is not a package manager in the same sense as Yum or Apt, because it manages libraries per project. Per project is exactly what allows a site to be updated independently and tested on its own.
Cloning, and the part with legal consequences
Refreshing staging from production is one of the most frequently run operations and one of the least examined.
A production database contains personal data. Copying it into an environment with looser access, longer retention and more people is a data protection decision, not a convenience. Sanitization belongs inside the clone operation itself rather than as a step somebody remembers, because a step somebody remembers is a step somebody eventually forgets.
The same applies to files. A private file directory copied into staging is still private data sitting in a less protected place.
Multisite, or many sites?
The word multisite carries two quite different arrangements, and automation designed for one is wrong for the other. It is worth being precise, because the distinction changes almost every operation above.
Drupal multisite in the strict sense is one codebase serving several sites, each with its own database and configuration. Operations become cheap in one direction and dangerous in another: a dependency update applies everywhere at once, which is efficient until a module upgrade suits nine sites and breaks the tenth. There is no per site release; there is one release with several audiences.
Many independent sites means separate codebases, separate releases and separate risk. Each site can move at its own pace. The cost is that every operation must be performed many times, which is precisely why the estate level automation above exists.
Most large estates are in fact a mixture, and the mixture is usually undocumented. The inventory is where it surfaces, and the answer changes real decisions:
- Whether an update is one action or forty.
- Whether a rollback affects one audience or all of them.
- Whether a site can be migrated on its own, or only with its codebase siblings.
- Whether retirement releases resources or merely removes a row from a settings file.
That last point is the practical trap. Retiring a site from a multisite arrangement frequently leaves its database, its files and its DNS entry in place, because nothing forced anyone to deal with them. Estates carry years of that. An automated retire operation is what turns it from an intention into a routine, and the classification in the site complexity assessment is where the arrangement per site is recorded so the plan can account for it.
What good looks like
Four demonstrations, none of which is a document.
- Create a new site end to end, from request to a working environment, without anyone opening a terminal.
- Restore a production backup into a scratch environment and show the content is there.
- Run a dependency update across the estate and produce a per site pass or fail report.
- Retire a site, and show what evidence was kept.
Number two is the one that most often fails on first attempt, and it fails on estates where backups have run faultlessly for years. A backup that has never been restored is a hypothesis, which is why it is treated at length in backup and disaster recovery.
Where this sits
Lifecycle automation is the row of the replacement list that people notice last and miss most, because it is the row a managed platform made invisible. It is not the delivery pipeline, which is covered in Azure DevOps for enterprise Drupal, and it is not the infrastructure, which is Terraform and Infrastructure as Code. It is the layer between them that makes an estate operable.
Its full context is Drupal cloud modernization services, and the honest way to test any of the above on your own estate is to try the four demonstrations. We are happy to run through them with you.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.