This comparison is usually framed as a cost argument, and cost is the least reliable part of it. The honest framing is that the two options trade different things, and which trade is right depends on facts about your organization rather than facts about the platforms.
What follows tries to be fair to both. A managed Drupal platform is a legitimate engineering choice that solves real problems well. So is a cloud account you operate. The failure mode is choosing either one by default.
What each option actually is
A managed Drupal platform is a product that bundles infrastructure with a set of operational capabilities specific to Drupal: environment provisioning, deployment workflow, lifecycle operations, backups, monitoring and support, exposed through an interface the vendor designs. You rent the outcome.
Cloud infrastructure you control is an account in your own name at a cloud provider, plus the automation and operating model you build or buy to run Drupal on it. You own the outcome, and you own the work of producing it.
The boundary being argued over is an old one with a formal description. NIST defines cloud computing through essential characteristics including on-demand self-service and resource pooling, and defines a private cloud as infrastructure provisioned for exclusive use by a single organization. A managed platform and an account you control can both satisfy that definition, which is why the decision is not about whether something is cloud, but about which layer of it you intend to operate.
The important asymmetry: the managed platform is a product with a boundary, and the cloud account is a capability with a scope. Comparing them like for like is what makes the cost conversation misleading, because the platform price includes labor that the cloud bill does not.
What a managed platform is genuinely better at
Worth stating plainly, because it is often skipped in favor of a lock-in argument.
- Time to a working environment. A new site, a new branch environment, a new developer sandbox in minutes rather than after a platform project.
- Operational competence you do not have to hire. Somebody else has already learned how this software behaves at three in the morning.
- A defined support boundary. When something breaks there is a number to call and a contract that says whose problem it is.
- Consistency across teams. Every project gets the same workflow whether or not that project has an engineer who cares about workflows.
- Predictable cost per site. Not necessarily lower, but easier to budget and easier to defend.
For an organization with a handful of sites, no platform engineering capacity and no unusual constraints, that bundle is frequently the correct answer and the analysis can stop there.
What a cloud account you control is genuinely better at
- Architectural freedom. The runtime can reach what it needs to reach. Integrations, network paths, data locations and adjacent services are decisions rather than support requests.
- Cost attribution. Spend resolves to resources, and resources resolve to sites and environments. That is a different thing from a lower bill, and it is often the more valuable one.
- Audit and evidence. Logs, configuration state and access records are yours, in your account, in the format your security function already consumes.
- Consolidation. Drupal stops being a special case that lives outside the estate and becomes another workload inside it, under the same identity, monitoring and recovery arrangements as everything else.
- Scale economics. The per site cost of a platform you operate falls as sites are added. The per site cost of a license generally does not.
That last point is why estate size changes the answer so sharply. The fixed cost of building the platform is the same for five sites and for fifty.
The honest cost comparison
Three costs are routinely left out of the second column, and leaving them out is how a migration business case fails eighteen months after approval.
- The build. Infrastructure as Code, pipelines, lifecycle automation, monitoring, backup and the self-service surface. This is a project, not a configuration exercise.
- The operating model. Somebody patches, watches, responds and improves it, forever. Whether that is a team, a partner or a rota, it is a recurring cost that the platform price previously absorbed.
- The migration itself. Discovery, classification, tooling, waves, validation and stabilization. Covered in the Drupal migration factory approach.
Against those, the cloud resource bill is usually the smallest line and the one most often quoted alone.
The comparison is only meaningful if the second column includes the whole bundle. What actually has to be rebuilt is the list to price against.
Lock-in, described accurately
Lock-in is a real consideration and an overused word. It is not a moral failing of a vendor. It is a measure of how much of your architecture would have to change if you left.
The useful question is not whether a dependency exists but whether it was chosen. Using a managed database is a dependency. Building an application that assumes a platform specific deployment mechanism, a proprietary file handling layer or a vendor specific caching behavior is also a dependency, and it is the kind nobody wrote down.
Portability does not mean migration is effortless. It means the architecture avoids unnecessary dependencies that make future change harder than it needs to be. An organization can run happily on a managed platform for years and still be deliberate about which of its dependencies are load bearing.
What changes operationally, day to day
The architecture diagrams make the two options look similar. The daily experience is where they diverge, and it is worth being concrete because this is what the people doing the work will actually notice.
On a managed platform, a developer asks the interface for an environment and gets one. A release follows the workflow the platform defines. When something is slow, the first move is a support ticket, and the evidence available is the evidence the platform chooses to expose. When a new requirement does not fit, the answer arrives on the vendor's roadmap or not at all.
On infrastructure you control, a developer asks a pipeline for an environment and gets one, if somebody built that pipeline. A release follows the workflow your organization defined, which is an advantage exactly to the degree that somebody thought about it. When something is slow, the evidence is already in your monitoring, and the first move is to look. When a new requirement does not fit, it becomes a backlog item that your team can prioritize.
Read that pair honestly and the trade is clear: the platform converts capability into a subscription, and control converts a subscription into capability plus obligation. Neither is free.
Two operational areas deserve specific attention because they are the ones organizations most often discover late.
- Patching cadence. A managed platform generally handles the parts of the stack below the application, and the schedule is theirs. In your own account it is yours, including the unglamorous parts: operating system, PHP, the database engine, the base image. The work is not difficult; it is relentless, and it needs an owner rather than an intention.
- Restore, not backup. Both options take backups. The difference is who has rehearsed a restore, and how recently. This is the single most common gap found during a migration assessment, and it is usually present on both sides of the comparison. Backup and disaster recovery covers what a defensible answer looks like.
The questions that actually decide it
In practice the decision turns on a small number of facts, and most organizations already know them.
- How many sites, and what is the growth curve? Below roughly a handful, the platform's fixed savings usually win. Across dozens, the build amortizes.
- Do you already run cloud infrastructure competently? If the organization operates other workloads in its own account, Drupal is an addition. If it does not, this is a new capability and should be costed as one.
- Are there constraints the platform cannot satisfy? Data location, network reachability, a required identity provider, an integration that has to run inside a boundary. A single hard constraint can end the analysis by itself.
- Where does the cost pressure actually come from? If it is the license, control helps. If it is the labor, control moves the labor rather than removing it.
- Who will own this in three years? The least technical question and frequently the decisive one.
The option people forget
The choice is not binary, and treating it as binary produces worse outcomes than either option.
A hybrid arrangement is common and often correct: an estate where the high traffic or high constraint sites move to controlled infrastructure while a long tail of low complexity sites stays where it is. The classification work in the Drupal site complexity assessment produces exactly the evidence needed to make that split defensibly rather than by intuition.
Equally common: controlled infrastructure with an external operating model. Owning the account is not the same as staffing a platform team, and the two decisions are separable. That is what enterprise Drupal managed services describes.
How to decide without a proof of concept
A full proof of concept is expensive and usually answers a question nobody asked. A cheaper sequence answers the real one.
- Inventory the estate and classify it. Size and complexity change the answer more than any other input.
- Write down the constraints that are genuinely non-negotiable, and test each against the current platform.
- Price the whole second column, including build and operating model, not the resource bill.
- Decide who owns the result in three years, and check the plan is consistent with that answer.
If the outcome is to move, modernizing an enterprise Drupal platform is the shape of the work that follows. If the outcome is to stay, the inventory and the constraint list are still worth having, because they are what makes the next review a decision rather than a repeat of this one.
Either way, the conversation worth having is about the estate.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.