I have been working in Drupal for over 10 years. And in that time, one question comes up on almost every single client call before a project starts:

"How long is this actually going to take?"

Most agencies answer with: "It depends." Which is technically true. But it is also completely useless when you are trying to set a budget, get sign-off from your board, or figure out whether December 9, 2026 is a real deadline problem or just background noise.

So this post does something most agencies avoid — it gives you actual numbers. Broken down by migration path, site complexity, and the real-world blockers that turn a 6-week project into a 6-month one.

No best-case scenarios. No padded estimates. Just what I have seen across years of Drupal projects.

First: Migration vs. Upgrade — These Are Not the Same Thing

This confusion costs businesses money. A lot of it. So let's clear it up before anything else.

An upgrade means moving between versions where the core architecture stays compatible. Drupal 10 to Drupal 11 is an upgrade. Most of the structure carries over. Custom code needs updates but the foundation does not change.

A migration means the architecture changed fundamentally between versions. Drupal 7 to Drupal 11 is a migration — not an upgrade. You are rebuilding the site in modern Drupal and migrating your content across. It is a different type of project entirely.

Why does this matter? Because an upgrade on a standard D10 site might take 3 weeks. A migration of the same site from D7 could take 4 months. Agencies that blur this line — intentionally or not — are the reason projects blow their budgets.

Real Timelines — By Migration Path

These are not optimistic estimates. These are realistic ranges based on actual project experience.

Drupal 10 → Drupal 11 (Upgrade)

→ Simple site (standard theme, few custom modules): 1–3 weeks

→ Medium site (contrib modules, custom theme): 3–6 weeks

→ Complex site (heavy custom code, integrations, multi-site): 6–12 weeks

The main variable is contributed module compatibility. Some modules release D11 support quickly. Others take months. If your site depends on a module that has no D11 release, you are either waiting, finding an alternative, or paying someone to build one. None of those options are free or fast.

Drupal 9 → Drupal 11 (Major Upgrade)

→ Simple site: 3–6 weeks

→ Medium site: 6–10 weeks

→ Complex site: 10–20 weeks

Drupal 9 reached end of life in November 2023. If you are reading this and still running D9, you are already on an unsupported platform. The path to D11 typically requires hitting D10 compatibility milestones first — a step many teams completely miss when scoping the project.

Drupal 7 → Drupal 11 (Full Migration)

→ Brochure / informational site: 6–10 weeks

→ Medium site (custom content types, contrib modules): 3–5 months

→ Enterprise site (multi-site, integrations, custom workflows): 5–9 months

Drupal 7 migrations sit in a category of their own. The architecture between D7 and modern Drupal changed completely — there is no direct upgrade path. You are essentially rebuilding the site from the ground up using modern Drupal and moving content across using the Migrate API. For a complex site, this is a significant engineering project, not a quick fix.

Drupal 7 reached official end of life in January 2025. If your site is still running on D7 today, you are already exposed. Every month you wait narrows your options and increases the risk that something breaks before you can get to safety.

What Actually Causes Delays — The Honest List

Most Drupal projects do not run over because of technical problems alone. In my experience, the delays are almost always predictable — and almost always avoidable if you know to look for them.

1. Undocumented custom code

The original developer left. Nobody documented what the custom modules do or why they were built a certain way. Now someone has to reverse-engineer years of decisions before a single line can be migrated safely. This alone can add weeks. On complex enterprise sites, it has added months.

2. Slow internal feedback loops

This is the single most common reason projects run long — and it has nothing to do with the development team. When a staging environment is ready for review and the client takes two weeks to respond, those two weeks come straight out of the project timeline. I have seen technically complete migrations sit in UAT for over a month, waiting for someone internally to approve the final sign-off.

3. Third-party integrations

CRM systems, payment gateways, marketing automation, analytics, booking systems — every integration is a separate workstream. Some have Drupal modules that need updating. Others require rebuilding the API connection from scratch. And occasionally, the third-party platform changed its API since the original integration was built, which means you are not restoring something — you are starting fresh.

4. Content that was never cleaned up

Old Drupal 7 sites are often content graveyards — years of pages, media files, taxonomy terms, and duplicated nodes that nobody has touched since 2018. Before that content can be migrated properly, it needs cleaning. Clients almost never build this into the project timeline. It almost always takes longer than anyone expects.

5. Scope creep mid-project

"While we're in there, can we also redesign the homepage and add a new checkout flow?" I hear this on nearly every project. Adding new features or a redesign to an in-progress migration is the fastest way to double the timeline. Migrations should migrate. New features should come after go-live, when the foundation is stable.

6. Module compatibility gaps

Some contributed modules your site relies on may not have D11 releases yet. Discovering this mid-project — rather than during a proper pre-migration audit — means stopping to find alternatives, write custom replacements, or wait for a maintainer to publish an update. This is one of the most preventable delays, and one of the most common.

The Pre-Migration Audit: The Step Most Teams Skip

The most valuable thing you can do before starting a Drupal migration is not choosing an agency. It is getting a proper technical audit of your current site.

A thorough audit will tell you:

→ Which contributed modules you rely on and their D11 compatibility status

→ How much custom code exists and how documented it is

→ Which third-party integrations need to be rebuilt versus updated

→ The volume and condition of your content

→ Existing performance and security vulnerabilities that will carry into the new site if not addressed

With audit findings in hand, a timeline estimate stops being a guess and becomes a plan. Teams that skip the audit are the ones that hit surprises in week 6 of a project that was supposed to be done in week 4.

The December 9, 2026 Deadline — What It Actually Means for Your Timeline

Drupal 10 reaches end of life on December 9, 2026. After that date: no security patches, no bug fixes, no official support. Your site does not stop working — but it becomes an increasingly easy target as vulnerabilities go unpatched.

Given the timelines above, here is the honest picture if you are starting today:

→ Simple Drupal 10 site: You can still make it — but you need to start soon.

→ Medium Drupal 10 site: It is tight. Starting today gives you a chance. Starting in October probably does not.

→ Complex site on any version: You are in risk territory. Every week you delay makes the outcome worse — higher cost, less time to test, more corners cut.

There is also a practical capacity problem: the Drupal agencies that do this work well are already getting booked. The teams waiting until November will find themselves choosing between a rushed job or operating on an unsupported platform through the new year.

How to Shorten Your Migration Timeline Without Cutting Corners

Start with a proper audit. Know what you have before you start moving it. This single step removes the biggest source of mid-project surprises.

Lock scope before kickoff. New features and redesigns come after go-live, not during. Put it in writing if you have to.

Assign a dedicated internal contact. Someone who can review staging environments quickly, make decisions, and respond to questions within 24 hours — not someone routing everything through three approval layers.

Clean your content before the project starts. Archive old pages, remove broken media, fix duplicate content. Doing this in parallel with planning saves time during the actual migration.

Work with a team that specialises in Drupal. A generalist agency that does occasional Drupal work will take significantly longer than a team that does it every day. Drupal has its own architecture, its own ecosystem, and its own edge cases. Experience is not optional — it is the difference between a clean go-live and a 3-month overrun.

The Bottom Line

Here is the straightforward answer:

→ D10 to D11 upgrade: 1 to 12 weeks

→ D9 to D11: 3 to 20 weeks

→ D7 to D11: 6 weeks to 9 months

The range is wide because every site is different. But get an audit done first and the range narrows to something you can actually plan around. You go into the project with a real number — not a hope.

Not sure where your site falls on that scale?

We offer a free Drupal site audit — no sales pitch, no obligation, no generic report.

You will get:

→ A clear breakdown of your migration complexity

→ A realistic timeline estimate based on your actual site

→ An honest view of your risk if you are still on an EOL version

→ Specific next steps — not a proposal, just a plan

December 9, 2026 is not a soft deadline. The window to do this properly is closing.

Book your free Drupal audit at drupalify.com — or email us directly. We respond within 24 hours.