Most organizations do not set out to modernize Drupal. They set out to solve something smaller: a cost line that will not itemize, a deployment that cannot be changed, an integration the runtime is not permitted to reach, an audit question nobody can answer without opening a support ticket. Modernization is what the answer turns out to be.
This guide is about what that answer actually contains. It is written for the person who has to sponsor the work and defend the plan, rather than for the person who will write the pipeline.
What is actually being replaced
The first useful correction is that a proprietary Drupal platform is not a hosting product. It is a bundle of operational capabilities that happen to be sold together, and most of them are invisible until they are gone.
An organization that migrates the application and forgets the bundle arrives somewhere worse than where it started: the same Drupal, running on infrastructure nobody has automated, with none of the operational scaffolding the old platform quietly supplied.
The bundle usually includes provisioning, code deployment, environment management, Drupal lifecycle operations, bulk actions across many sites, monitoring, self-service for delivery teams, backup and restore, security tooling, and somebody accountable when it breaks. Every one of those needs a named replacement before the first production site moves. We work through the full list in what actually has to be rebuilt when you replace a managed Drupal platform.
Ownership is the point, not the cloud
The word cloud does very little work in this conversation. Both the old platform and the new one run in a cloud. What changes is who holds the account, who can inspect the resources, and who is able to change something without asking.
NIST is worth borrowing here because its definitions are precise where marketing language is not. In SP 800-145 the essential characteristics of cloud computing include on-demand self-service and resource pooling, and a private cloud is defined as infrastructure provisioned for exclusive use by a single organization. That last phrase is the one that matters: exclusivity of use is a property of the arrangement, and it is worth knowing which arrangement you are actually buying.
Practically, ownership shows up as a short list of things that stay true after the project ends.
- The cloud subscription, its billing and its audit trail belong to the organization.
- The application is a standard Drupal codebase managed with Composer, which describes itself as a tool for dependency management in PHP.
- Site configuration is in version control and imported on deploy, so an environment is rebuilt from what is written down.
- The infrastructure is declared in code the organization holds.
- The runbooks are deliverables rather than knowledge held by whoever is on the account.
None of that makes a future migration effortless. It makes it ordinary, which is a different and more achievable goal.
The architecture, in the order a request travels
A target architecture for enterprise Drupal is not exotic. It is a conventional web architecture with the state-holding parts treated seriously: edge protection, load balancing, an application runtime, separated environments, data services, security services, observability, protection and recovery, and the automation that makes all of it repeatable.
The detail, layer by layer, is in the enterprise Drupal reference architecture. What matters at this level is that no single vendor stack is required, and that a design which cannot be rebuilt from its own definitions is not finished.
Three tools, three different jobs
A recurring confusion is worth heading off early, because it leads teams to automate the wrong layer.
- The delivery plane orchestrates workflow: source control, build, test, security gates, approvals, promotion and rollback. Microsoft describes Azure Pipelines as combining continuous integration, continuous testing and continuous delivery to automatically build, test, and deploy code projects to any destination. That last clause is load bearing, and it is why Azure DevOps can run delivery for Drupal workloads that live somewhere else entirely.
- Infrastructure as Code declares the environment. HashiCorp describes Terraform as an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. See Terraform and Infrastructure as Code for Drupal.
- Drupal lifecycle tooling performs the operations only Drupal can perform. Drush describes itself as a command line shell and Unix scripting interface for Drupal, and its deploy command standardizes how Drupal deployments work. See Drupal lifecycle automation.
Choosing one of the three and expecting it to cover the other two is the most common way these programs stall.
Migrating many sites is a different problem from migrating one
A single site migration is a project. Twenty site migrations run as twenty projects is twenty times the risk and none of the learning. The alternative is to build the repeatable path first and then run volume through it, which is the idea behind the Drupal migration factory approach.
Two decisions do most of the work.
Classify before you sequence. Score every site on version, custom code, data volume, integrations, authentication, search, traffic, criticality and technical debt. The result drives pilot selection, order, test depth, rollback requirements and acceptance criteria. That is the subject of the Drupal site complexity assessment.
Move in waves, not in one night. Group sites so each wave teaches the next, and treat the platform itself as the first wave. Sequencing a large estate covers the shape and the traps. The number of waves is a property of your estate; any plan that arrives with the waves already decided has not looked at it.
Whatever the sequence, one rule does not vary: rollback stays available until acceptance is confirmed. Cutover and rollback is where that rule is turned into a procedure.
Security belongs in the pipeline
The reason to talk about DevSecOps in a modernization guide is that a migration is the rare moment when the delivery process is genuinely open for change. Retrofitting security gates into a settled pipeline is harder than building them into a new one.
NIST puts the principle plainly in SP 800-218, which recommends a core set of high-level secure software development practices that can be integrated into each SDLC implementation. In practice that means validation on the pull request, dependency scanning, a software bill of materials, build provenance, dynamic testing before promotion, and a deliberate approval gate. What Drupal DevSecOps means covers the concept and building the pipeline covers the implementation.
The runtime half is separate and equally necessary: edge protection, transport security, identity, least privilege, secrets management, hardening and centralized logging. That is Drupal cloud security architecture.
What happens after go live
The most common failure in these programs is not technical. It is that the platform is delivered and then nobody owns it.
Three capabilities decide whether the architecture stays true. Observability tells you what the platform is doing. Backup and disaster recovery decides what survives a bad day, and NIST defines the two objectives that matter precisely: 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. Self-service platform operations decides whether delivery teams can act without waiting.
Around all three sits an operating model. Whether that is internal, external or shared, it needs naming before go live rather than after. Enterprise Drupal managed services describes what that usually contains.
A sensible order
If the whole program were reduced to a sequence, it would be this.
- Inventory the estate and classify it. Nothing else can be planned honestly first.
- Decide the target architecture once, for the whole estate.
- Build the platform from Infrastructure as Code, and prove it can be rebuilt.
- Build the pipeline, including the security gates, before the volume arrives.
- Pilot with representative sites rather than easy ones.
- Migrate in waves, with rollback available until acceptance.
- Stand up observability, backup and recovery, and rehearse the restore.
- Name the operating model and hand over deliberately.
Steps three and four are the ones organizations are most tempted to compress, and compressing them is what turns a factory back into twenty projects.
Where LABUSA fits
LABUSA combines enterprise architecture, cloud infrastructure, cybersecurity, DevOps, Drupal platform operations and managed services, which is the combination this work needs. LABUSA's own capabilities span private infrastructure, public cloud, cybersecurity, enterprise architecture and AI implementation, and it operates hybrid infrastructure combining privately hosted infrastructure with AWS, AWS GovCloud (US) and Microsoft Azure services.
The architecture described across this cluster is a reference model offered as an engineering approach. It is not a description of work already delivered for any particular organization, and nothing here should be read that way.
If you are weighing this decision, the enterprise Drupal cloud modernization capability page is the shortest route to the whole picture, and a conversation about your estate is more useful than a conversation about a destination.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- Composer, Introduction, Composer documentation
- Microsoft, What is Azure Pipelines?, Azure DevOps documentation
- HashiCorp, What is Terraform?, Terraform documentation
- Drush, Drush 13 documentation
- Drush, Deploy command, Drush 13 documentation
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218
- NIST, Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1
- NIST, The NIST Definition of Cloud Computing, SP 800-145, September 2011