How Long Does a Drupal 10 to 11/12 Migration Actually Take for a Government Site?
Short answer: a Drupal 10 to 11 upgrade takes anywhere from a few hours to about nine weeks. A simple site can be done in a day. A complex enterprise platform with unmaintained modules and heavy custom code is a four to nine week effort. The duration depends almost entirely on how much non-core code your site carries, not on how many pages it has.
That surprises people who lived through Drupal 7 to 8. It should. The two are not the same kind of work, and budgeting for one when you are facing the other is how agencies end up either overpaying or missing a deadline.
Estimated timelines by site complexity
| Site profile | Characteristics | Upgrade duration |
|---|---|---|
| Small / simple | Fewer than 20 contributed modules, standard or lightly customized theme, no complex custom code | 1 day or less |
| Medium | Moderate contributed module footprint, some custom code, staging environment to validate against | 1 to 2 weeks |
| Large / enterprise | Incompatible or unmaintained contributed modules, substantial custom modules and custom entity types, extensive QA requirements | 4 to 9 weeks |
A medium-site upgrade is mostly dependency auditing, Composer updates, fixing minor deprecations, and testing in staging. The enterprise number is driven by the two genuinely unpredictable items: patching or replacing contributed modules that have no Drupal 11 release, and refactoring custom code that calls deprecated APIs.
What actually determines your number
Contributed modules. If the modules you depend on already have Drupal 11-ready releases, the upgrade moves fast. If you rely on code whose maintainer stopped publishing in 2023, you are choosing between finding a replacement, adopting the module yourself, or writing and maintaining patches. This single factor separates a one-day upgrade from a six-week one more than anything else. The Project Update Bot files compatibility patches against many contributed projects automatically, so check there before assuming a module is abandoned.
Custom code. Sites with heavy custom modules or custom entity types need a scan for deprecated function calls and then a refactor. Drupal Rector automates a meaningful share of that work, but not the parts requiring judgment about how your code was meant to behave. Custom theme JavaScript needs its own pass, because Drupal 11 ships jQuery 4.
Preparation. Running the Upgrade Status module before you scope anything gives you a defensible list of your specific blockers. It takes an afternoon and converts a vague risk into a line item you can fund and defend in a schedule review.
The prerequisites that trip up agency sites
More upgrade schedules die here than in the code.
You must be on Drupal 10.3.0 or later. Update paths from earlier releases were removed from Drupal 11. A site sitting on 10.1 or 10.2 needs an intermediate step before it can start.
Major versions cannot be skipped. A Drupal 9 site cannot go directly to 11. It goes to 10 first, then 11. If you are among the roughly 10% of the installed base still on Drupal 9, you are running two upgrades, not one.
PHP 8.3 or later, moving to 8.5 for Drupal 12.
Database minimums are real blockers. MySQL 8.0, MariaDB 10.6, PostgreSQL 16, or SQLite 3.45. Backport modules exist as a temporary bridge for older MySQL and MariaDB, but they are a bridge, not a destination. PostgreSQL 16 in particular catches agencies running older managed database instances they do not directly control.
Microsoft IIS is no longer supported. If your site runs on Windows and IIS, Drupal 11 is a hosting migration before it is a CMS upgrade, and the schedule looks nothing like the table above. Find out now, not in October.
On a FedRAMP-authorized platform, every item in this list is your provider's roadmap rather than yours. Get their commitment dates in writing before you build a schedule around them.
Why this is not a rebuild
Drupal 8 onward uses a continuous upgrade path. Each major release is the prior release with deprecated code removed. Your content database carries forward. Configuration carries forward. Views, content types, taxonomies, media, and permissions survive intact. Nothing gets migrated node by node.
The Drupal 7 to 8 move was different in kind. New architecture, new theme layer, content moved through the Migrate API. Agencies spent a year and seven figures on that transition, and the memory still shapes how program offices estimate anything with "Drupal migration" in the title. If your last data point is 2018, discard it.
The dates that set your deadline
- December 9, 2026: Drupal 10 reaches end of life. No further releases, including security releases.
- Week of December 7, 2026: Drupal 12.0.0 and Drupal 11.5.0 are scheduled to release.
- Already passed: security coverage for Drupal 10.5.x and 11.2.x ended with the Drupal 11.4 release in June 2026.
After December 9, a Drupal 10 site gets no security patches from the Drupal Security Team. For a system with a live ATO, that becomes a continuous monitoring finding, and eventually an audit item.
Plenty of organizations are not ready. W3Techs measured roughly half of detected Drupal sites running end-of-life versions as of August 2026, with Drupal 10 at 30.6% of the installed base and Drupal 11 at 19.2%. Drupal.org's own telemetry put obsolete installs near 43% of reporting sites.
What leaves core, and why it matters to you
Modules removed in Drupal 11: Actions UI, Tracker, Book, Forum, Statistics, and Tour. Book is the one to check first on a government site, because agencies use it constantly for handbooks, manuals, and multi-page policy documents. Statistics is the second, since it often quietly backs a reporting requirement somebody still cares about.
Modules removed in Drupal 12: Ban, Contact, Field Layout, History, Migrate Drupal, and Migrate Drupal UI. Contact deserves attention for the same reason, because a lot of agency sites use it for the public-facing contact form and nobody has decided what replaces it.
Every one of these has a contributed replacement available. The work is identifying the dependency before the upgrade, not after.
Drupal 11 to 12 is the easy one, if you stay current
Drupal 12 requires PHP 8.5 and drops all core update paths prior to 11.3.0. A site has to reach Drupal 11.3 or later before it can move to 12 at all, so a team that upgrades to 11.0 and stops has bought itself a second hop. For a site already on a current 11.x release with maintained dependencies, the move to 12 is routine maintenance rather than a project.
What you get on the other side
Worth putting in the business case, since the upgrade is usually sold as pure compliance cost. Drupal 11 targets WCAG 2.2 AA and treats accessibility barriers as bugs rather than feature requests, which strengthens rather than complicates your 508 posture. Workspaces supports content staging and review across environments, which maps directly onto the multi-office clearance workflows most agency sites run on. Single-Directory Components bring the theme layer closer to how modern front-end teams already work, and Recipes package common functionality for reuse across sites.
What adds calendar time on a government site
None of the following makes the upgrade take longer. It changes when you are allowed to start and when you are allowed to launch, and on a federal site that wrapper is routinely longer than the engineering inside it. Program managers who plan for engineering alone are the ones who miss dates.
Security authorization. A version upgrade on an existing system is usually a significant change requiring ISSO review rather than a full reauthorization. Get that determination in writing in week one. If the answer comes back as a full reassessment, the schedule changes by months and you want to know before you obligate funds.
Accessibility revalidation. Conformance has to be re-verified after any theme or component library change. If the upgrade also moves you to a newer USWDS version, budget remediation on top of testing. Automated scanning catches a fraction of what a manual audit catches.
User acceptance testing. Fifty thousand nodes is not a technical problem. Fifty thousand nodes owned by fourteen program offices that each want to review their own pages is a scheduling problem, and it is usually the longest single item on the calendar.
Integrations. Login.gov or departmental SSO, Salesforce or ServiceNow connections, search appliances, data feeds. Each needs its own regression test and often its own point of contact who does not report to you.
Procurement. If the work is not already within scope of a current task order or available on an existing vehicle, the acquisition timeline can exceed the technical timeline several times over. A one-week upgrade sitting behind a four-month competed action is still a four-month project.
The practical lever is sequencing. Run the ISSO conversation, the accessibility baseline, and the UAT coordination in parallel with the code work rather than after it. A medium site that runs them sequentially takes two to three months of elapsed calendar for one to two weeks of engineering. Run them in parallel and the same work lands in three to four weeks.
What to do in the next 90 days
December 9 is thirteen weeks out. That is enough time for most agency sites, provided the process items start now rather than after the code is done.
- Run an Upgrade Status audit this month. One afternoon produces the module and custom code inventory that everything else depends on.
- Verify you are on Drupal 10.3 or later. If not, that update comes first and it is not optional.
- Confirm your platform against the full requirement list. PHP, database version, and web server. An IIS or PostgreSQL finding changes the whole plan, so surface it early.
- Get the ISSO's significant-change determination in writing. This single answer drives your entire schedule.
- Target Drupal 11.3 or later, so your next major version is maintenance rather than another project.
- If you cannot land before December 9, document it. An unpatched CMS with a POA&M and a remediation date is a manageable finding. The same CMS with no plan is not.
The planning point worth keeping
Agencies that handle this well are not the ones with the biggest budgets. They are the ones that stopped treating major version upgrades as discrete projects and started funding them as routine maintenance, the same way they fund patching for every other system. On the current two-year major release cycle, a site that stays on the latest minor release is never more than days or weeks from the next major version. A site that falls two majors behind is running two upgrades back to back, and a site that falls further is looking at a rebuild.
Agileana has been building and maintaining Drupal for federal agencies since 2007, including work for the National Archives, the U.S. Courts, the FCC, and the Georgetown University and U.S. Department of State English Language Programs site. We hold GSA MAS, NASA SEWP VI, and BPAs with NARA, DOT, and the U.S. Courts, and we are ISO 9001 certified, CMMI Level 2 appraised, and an Acquia partner.
If you want a defensible number for your specific site instead of a range, an upgrade assessment produces one in about a week: the module inventory, the custom code findings, the platform gaps, the accessibility baseline, and a phased schedule your ISSO and your contracting officer can both work from. Get in touch and we will scope it.