The question reaching architecture meetings this year almost always comes framed as a choice between two paths: migrate to Drupal 11 now, or hold the portal as is and jump straight to Drupal 12 once it ships. It sounds reasonable, and it appears to save an entire project.
The calendar the Drupal Association has published closes that door. Drupal 12 ships the week of December 7, 2026, and reaching it carries an explicit technical requirement: a site has to be on Drupal 11.4 or later before updating, with a strong recommendation to be on 11.5. There is no supported path from Drupal 10 straight to Drupal 12. Whoever waits for Drupal 12 does the exact same migration work, only later and with the support window already closed.
That reframes the conversation. The three reasons below are the operational consequences of a calendar that is already fixed and runs independently of any organization's internal planning.
Reason 1: Security patches for Drupal 10 stop on December 9, 2026
Drupal 10 shipped on December 15, 2022, and reaches end of life on December 9, 2026. Version 10.6 is the last minor release on that branch. After that date there are no more releases: a core vulnerability reported in January 2027 against a Drupal 10 portal has no official patch, and the organization is left with three options, all of them costly. Patch it in-house, contract extended support if one exists for the case, or migrate under incident pressure.
For a university portal handling tuition payments, or a healthcare portal exposing scheduling and patient data, that third option is the one that tends to happen. And a migration executed during a security incident happens without a testing window, without a rollback plan, and with the team fielding communications in parallel.
The date matters for a practical reason that tends to get lost in the technical discussion: budget cycles at enterprise institutions in the region close between September and November. A portal without the migration inside its 2027 approved budget will spend the first months of the year without core support and without a line item to fix it. The budget decision comes due before the technical one does.
It is worth separating two things people tend to conflate. End of support does not shut anything down: a Drupal 10 portal keeps running on December 10 exactly as it did the day before. What changes is that the community stops producing the patch, and the risk moves from being distributed across the project to being concentrated on whoever operates that portal.
Reason 2: Drupal 11 is the step on the way to Drupal 12
This is the point that changes plans the most once it comes up in an architecture session.
Drupal core's deprecation process works by accumulation. When a new API is added, the previous one gets marked deprecated and scheduled for removal in a later major version. The result is a continuous upgrade path between majors, on the condition of staying current on the active branch before jumping to the next one. For Drupal 12 that condition is written down: sites on 11.3 or earlier must first update to 11.4 or later, because all upgrade code prior to that version has been removed.
For a portal running Drupal 10 today, the reading is direct. Migrating to Drupal 11 is work that has to happen under any scenario, and the only real degree of freedom is whether it happens on the organization's own schedule or against the December deadline.
There is a difference in kind between the two jumps worth keeping in mind when scoping. Moving from Drupal 10 to Drupal 11 means auditing every contributed module's status, removing deprecated code from the custom profile, and upgrading the PHP version. Drupal 11 starts at PHP 8.3, while Drupal 10 still supports installs on 8.1, so on many legacy portals the platform upgrade is part of the scope, not a prerequisite already handled. In the enterprise portals we have supported, that infrastructure component tends to be the one that most surprises the initial estimate, especially when hosting is self-managed and the maintenance window has to be negotiated across several teams.
Reason 3: What the migration buys is that the next jump stops being a project
The third reason is what sustains the business case beyond 2026, and it depends on a community decision that went fairly unnoticed.
Disruptive deprecations introduced since Drupal 11.3 were scheduled for removal in Drupal 13, not in Drupal 12. The intent was to give contributed module ecosystems room, so a maintainer can support the next major and the currently supported minors on the same codebase. The side effect for whoever runs a portal is more concrete: the jump from Drupal 11 to Drupal 12 keeps backward compatibility on the APIs that matter and looks a lot more like a routine update than a migration.
A portal that reaches December 2026 on Drupal 11.5 has ahead of it a core update its team can run inside a normal maintenance window. A portal that reaches it on Drupal 10 has ahead of it a project with discovery, budget, regression testing, and a change committee.
That is the argument that works in front of a finance committee, and it is worth framing it in those terms: the 2026 migration pays for itself in the 2027 cycle, because it converts a recurring project expense into an operational task. In institutions running several portals on the same platform, that shift multiplies across every site. A multisite with twelve portals that today requires coordinating twelve migration plans comes to require a single coordinated update window instead.
The reason to wait
There is one case where starting the migration this quarter is the wrong call, and it shows up more often than the calendar suggests.
If the portal depends on a critical contributed module with no version compatible with Drupal 11 yet, and that module sustains a business function with no substitute, the date that governs the plan is set by that module's maintainer. Starting the migration without that dependency resolved produces a predictable outcome: the team reaches the end of the project with a fully updated core and a business function turned off, and the institution ends up carrying its own fork of the module indefinitely.
The right sequence in that scenario starts with the dependency inventory and leaves the core for later. It is worth doing this week, because it is fast and defines everything else:
- List the contributed modules the portal has enabled in production, separating the ones that are conveniences from the ones that sustain a business function.
- Check the Drupal 11 compatibility status on drupal.org for each module in the second group, and the date of the maintainer's last commit.
- For the ones without a compatible version, choose between three paths with a name and an owner attached: contribute the compatibility patch, replace the functionality with core capabilities, or drop it from scope.
The outcome of that inventory defines whether the migration is a three-month project or an eight-month one, and it is what lets you walk into a budget committee with a defensible number. In the enterprise portals where we have run this exercise, the list of truly critical modules is almost always shorter than the team expected, and a good share of what looked like a blocker turns out to be functionality core already absorbed in one of Drupal 10's minor releases.
It is also worth naming a case that often gets presented as a reason to wait. A pending redesign of the portal holds up better as a separate project: the two efforts have different dependencies, and coupling them tends to produce a scope that closes neither. The path that has worked best is migrating first on the current design and opening the redesign afterward, already on Drupal 11, where the platform's visual building capabilities change the starting point of that conversation.
What a plan that reaches December looks like
There is just under three months of usable calendar left, discounting the year-end weeks when most institutions freeze production changes. That is enough time for a portal of medium complexity whose module inventory comes back clean, and it is tight for a multisite.
The distribution we have seen work splits that time into three uneven blocks. Inventory and dependency resolution take up the first stretch and are where the outcome of the rest gets decided. The PHP and hosting platform upgrade runs in parallel, because it depends on third parties and has its own approval timelines. Core migration and regression testing occupy the final stretch, and there the factor that weighs the most is the automated test coverage the portal already had before starting.
That last point deserves a warning. A portal without automated tests can still be migrated, but the cost shifts to manual QA, and the functional team that has to run it is usually the same one closing out the year. If the portal does not have that coverage, better to know it in September than in November.
For institutions running their platform through ecosystem providers, it is worth adding an early conversation with them. Both Acquia and Dropsolid run their own version certification and managed environment update calendars, and those timelines rarely line up with the organization's own. Asking in September for the date their platform supports Drupal 11.5 avoids finding out in November that the available window is different from what was planned.
What comes after December
Drupal 12 launches the shortest major release cadence the community has adopted in recent years, and that carries a consequence not yet built into most platform plans in the region. Major version updates stop being an event every four or five years and become a calendar routine, on the order of what is today a minor update.
Organizations that reach 2027 with that routine already in place are going to operate with an advantage that compounds: they will be receiving the AI capabilities entering Drupal core in the cycle they ship, while everyone else evaluates them a version behind. By 2028, running the current major version is going to be the normal state of an enterprise portal, and the exception is going to be the portal that fell behind. That is the real difference a migration run on its own schedule buys.
The pattern repeats across the more than 40 enterprise portals we support in production across Latin America, several of them multisite and some with more than eight years of continuous operation on the same platform: the migrations that land on time are the ones that spent the first weeks on dependency inventory, and the ones that overrun are the ones that fixed the go-live date first and adjusted scope afterward. Sixteen years watching the same order of causes, with Drupal Certified Partner Platinum and Acquia Elite Partner in the region as the frame from which we support these migrations.
For the feature-level detail of what Drupal 11 brings, before building the internal case, see Drupal 11 Innovations. And if your organization's conversation is still a step earlier, on whether the platform should be a DXP or a CMS is enough, that framework lives in What Is a DXP and Does Your Company Really Need One?.