Migrating to Drupal 12: What It Really Costs, and the Question Nobody's Asking

If you run a Drupal site, you already know a deadline is coming. Drupal 10 reaches its official end of life in December 2026. After that date, the Drupal Security Team stops issuing patches for Drupal 10 core and contributed modules. Any vulnerability found after that day has no official fix.

"how do I migrate to Drupal 12?" It's a fair question. But before you approve another migration budget, it's worth asking a second one that rarely makes it onto the planning doc: why does this keep happening, and how much is it costing you every time?

Let's get the facts on the table, because a lot of the advice floating around gets the dates wrong.

Drupal moves to a new major version every two years, in even years. According to the official Drupal core release schedule, Drupal 12 is now targeting the week of August 10, 2026. The project uses a multi-window approach with later fallback windows, but mid-August is the current working target.

Here's the part that trips people up: Drupal 12 will be a brand-new .0 release the day it lands. Drupal 10, meanwhile, keeps its security support until December 2026. 

Moving a production site onto a just-released major version is rarely the safe play, so for most teams upgrading in 2026 the practical destination is Drupal 11, not 12. It's already stable and its contributed-module ecosystem is mature.

But keep one date in mind while you plan: Drupal 11 itself reaches end of life around 2028, roughly six months after Drupal 13 arrives. In other words, the upgrade you do in 2026 buys you about two years before the exact same exercise, the compatibility audit, the module checks, the custom-code fixes, comes back around. 

That two-year horizon is the whole reason it's worth asking a bigger question now, before you commit the budget.

A few more dates that matter:

• Sites on Drupal 10.5.x lose security support in June 2026, roughly six months before the full Drupal 10 EOL. If you're on 10.5, you need to move to 10.6 before then, or go directly to Drupal 11.
• The Drupal 10 to 11 jump is the smallest major-version upgrade in Drupal's history. The most disruptive API removals were deferred to Drupal 13, so the code-level delta is comparatively small.
• Major Drupal upgrades still have to be done sequentially: you can't skip across versions.

None of this is a knock on Drupal. It's a genuinely powerful, flexible, open-source platform, and its two-year cadence is more predictable than it used to be. The Drupal community deserves credit for that. The issue isn't the software. It's the operating model that comes with it.

Here's where the planning doc and the invoice tend to diverge.

To be fair, the near-term Drupal 10 to 11 hop is, on its own, one of the cheaper moves in Drupal's history. The bigger numbers below describe heavier re-platforms and the full multi-year cost of owning a Drupal site, not a single minor jump. That distinction matters, because the real expense isn't any one migration; it's the pattern that repeats around it.

Industry estimates put the headline number for a major Drupal migration across a wide range, from a few thousand dollars for a simple brochure site to roughly $85,000 to $250,000+ for complex, custom-module-heavy or multi-site rebuilds. But the sticker price is only part of the story. The number that matters is total cost of ownership over time, and that's where it gets uncomfortable:

Agency estimates commonly put a three-year Drupal TCO at around 1.7 to 2.6 times the initial build cost. On those figures, a $150,000 build carries a three-year total of roughly $260,000 to $360,000, and a $300,000 enterprise platform can approach $540,000 to $720,000.

Where does all that money tend to go? Broadly, industry breakdowns attribute roughly 35% to 45% to maintenance and support, 15% to 25% to hosting, 10% to 15% to security and updates, and the rest to feature work. For enterprise deployments, ongoing maintenance and support (security fixes, performance tuning, core upgrades, minor features) is often quoted at $2,000 to $8,000 per month. Your own numbers will vary, but the shape is consistent: the build is the small part.

The custom code trap

Now the part that stings most, and the part that likely prompted this whole article.

The single biggest cost variable in any Drupal migration is the custom code and contributed modules that have no equivalent in the new version and must be rebuilt. Every custom module you commissioned to make Drupal do the specific thing your business needs is a module someone has to test, patch, and often re-engineer at each major upgrade.

You pay to build custom functionality. Then, every couple of years, a major version arrives and you pay again, not for new capability, but to make the thing you already own keep working. The functionality doesn't improve. Your business doesn't move forward. You're spending real money to stand still.

And delaying doesn't help. Putting off an upgrade almost always makes it more expensive: technical debt compounds, security gaps widen, and hosting-environment incompatibilities pile up until the eventual migration is bigger and riskier than the one you skipped. Planned upgrades spread the cost out; deferred ones concentrate it. Either way, the cost is structural: it's baked into the model.

So here's the reframe. If you're evaluating a Drupal 12 (really, Drupal 11) migration right now, you're implicitly answering "how do we do the next upgrade?" But there's a prior question:

Do we want to keep buying upgrades at all?

Because the migration you're budgeting for in 2026 is not a one-time event. It's an installment. Drupal 13 is already on the roadmap. Then 14. The same custom-code audit, the same module rebuilds, the same six-figure TCO conversation will come back around on a two-year clock, indefinitely, for as long as you own the platform.

When open source earns its keep

For some organizations, that's an acceptable trade. If you have an in-house Drupal team, deep customization needs, and a preference for total control over your stack, open source earns its keep. That freedom is real, and it's worth paying for when you'll actually use it.

But a lot of teams aren't in that situation. They inherited a Drupal site, they don't have a standing Drupal team, and every upgrade means going back to an agency with an open checkbook. For them, the platform's greatest strength, infinite customizability, has quietly become the source of a recurring bill they never chose.

This is where managed, SaaS-based platforms change the math, and it's worth being precise about why, rather than just asserting they're cheaper.

On a SaaS platform, updates happen automatically in the background. New features, performance improvements, and security patches arrive without you scheduling a migration project, auditing custom modules, or booking agency hours. There's no "end of life" date hanging over you, because there's no version for you to be stranded on. 

The vendor maintains the platform; you use it. Hosting, updates, security, and support are wrapped into a predictable subscription instead of arriving as separate, unpredictable invoices.

It isn't only the big version jumps

The ongoing minor updates are where a lot of the friction actually lives. Teams already on Drupal 11 regularly find that even a routine point release can break a contributed module, that it's wise to check each module's issue queue before updating, and that a bad update can take a site down until a developer steps in. 

On the current model, an update is a project you schedule and staff, not something that simply happens in the background.

What you're actually paying for

That's the structural difference. It's not that SaaS is magically cheaper on day one; a naïve five-year projection that ignores added users, integrations, and premium features can flatter open source. 

The difference is what you're spending money on. On the Drupal model, a large share of your ongoing spend goes to keeping what you have alive. On a managed model, that maintenance-and-migration line largely disappears, and your spend goes toward using and growing the platform.

This is the space Core dna was built for. It's a fully managed platform that unifies content and commerce operations across every property you run, with updates delivered automatically, so there's no version to migrate off of and no custom-code rebuild waiting for you every two years. 

For a marketing team or a business owner who wants their website to move the business forward rather than absorb budget just to keep running, that shift, from maintaining to building, is the whole point.

There's a bigger reason this matters right now, and it's the clearest illustration of the difference between the two models.

Start with how routine updates work today. On a typical Drupal build, even everyday content and configuration changes, importing a data set, adjusting a layout, fixing a navigation menu, often can't be done from the admin screen alone.

 They lean on developer tooling like Drush and Composer, or a ticket to the dev team. For a marketer, that dependency is the real day-to-day tax, and it's the backdrop for what's coming next.

The way websites get updated is changing. With the rise of MCP (Model Context Protocol), the emerging standard that lets AI agents like Claude actually do things in your systems, not just talk about them, a marketer will increasingly be able to update a website by asking for it: "update the pricing across all our stores," "publish this blog post to three properties," "swap the homepage banner for the sale." 

The agent makes the change directly, across every property, without a ticket to the dev team.

That's a genuine unlock for marketing. It collapses the gap between deciding to change something and shipping it. And it's exactly the kind of capability where platform model matters more than platform version.

Where Drupal stands today

Drupal is not standing still: there are community MCP modules in the works, and they're promising. But as of early 2026 they're still contributed, beta-stage modules (the MCP tooling was at v1.0.0-beta2 with only a handful of production sites reporting usage), and they follow the same pattern as everything else in the ecosystem: the community has to build it, and then you have to install, configure, secure, and maintain it yourself. 

If you want AI-driven updates working efficiently on Drupal, you're once again waiting on modules to mature, and once they do, they become one more layer of custom plumbing to carry through the next major upgrade.

On a managed platform, that capability is part of the product. Core dna exposes its platform through MCP natively, so an AI agent can read and update content, products, pricing, and pages across your properties out of the box: maintained by the vendor, updated automatically, with nothing for you to assemble.

 It's the same story as the upgrade treadmill, just pointed at the future instead of the past: on one model you wait for the community to build the capability and then you maintain it; on the other, it's simply there.

That's the real change worth planning around. The question isn't only "what does the next migration cost," it's "which model lets my marketing team actually use what's coming next?"

How to actually decide

If your Drupal 10 EOL deadline is forcing a decision, run it through three honest questions:

1. What are we really paying to maintain? Add up the last three years of Drupal spend: build, hosting, retainers, security, and the last migration. Not the sticker price; the total. That number is your real baseline, and it's the fairest thing to compare any alternative against.

2. How much of our custom code exists to serve the business vs. to make Drupal behave? If a meaningful chunk of your custom modules are effectively plumbing (glue code to integrate systems or replicate features a modern platform offers out of the box), you're paying to maintain complexity, not capability.

3. Are we going to use the control open source gives us? If you have the team and the appetite for it, upgrade to Drupal 11 and plan the cadence. If you don't, if every upgrade is an outsourced fire drill, that's the strongest possible signal that the platform model, not the platform version, is the thing to change.

Migrating to Drupal 12 is a real, near-term decision with a hard deadline: Drupal 10 support ends December 9, 2026, and Drupal 11 is the sensible destination for most teams upgrading now. If Drupal is the right fit for your organization, plan the move early: deferring it only makes it cost more.

But if you keep finding yourself paying to fix and rebuild custom code every couple of years just to keep the lights on, the upgrade in front of you isn't the problem. It's a symptom.

The real decision isn't which Drupal version comes next. It's whether you want to be answering that question again in 2028, and 2030, and every even-numbered year after that.

There's another way to run a website: one where the updates are simply done for you, and your budget goes toward growth instead of maintenance. Before you sign off on the next migration, it's worth asking whether that's the model you actually want.