Questions to answer before a Drupal upgrade

A Drupal upgrade is rarely just a software update. For sites that have been running for years, moving to a current version usually means rebuilding parts of the platform, migrating content, and revisiting decisions that were made long ago. Answering a few questions early makes the project easier to estimate, easier to approve, and far less likely to surprise anyone halfway through.

What do you actually have today?

Start with an honest inventory. List the Drupal version, every contributed module, and every custom module. Note which contributed modules have current releases and which have been abandoned. Custom modules deserve special attention, because each one represents business logic that will need to be rewritten, replaced by a maintained module, or retired.

Do the same for content. How many content types, fields, taxonomies, and views exist? Which ones are still used? Many long running sites carry content structures that nobody remembers creating. Every structure you can retire is one you do not have to migrate.

What depends on the site?

Integrations are where upgrades most often go wrong. Identify every system the site sends data to or receives data from: single sign on, CRMs, payment processors, search, email platforms, analytics, and internal databases. For each one, find out who owns it, how it connects, and whether the connection method is still supported.

Who uses it, and how?

Talk to editors, administrators, and the people who rely on the site's information. Ask what frustrates them and what they work around. An upgrade is a good opportunity to fix editorial workflows, permissions, and accessibility problems, but only if you know about them before planning begins.

What does success look like?

Teams upgrade for different reasons: security support, easier editing, better performance, accessibility, a refreshed design, or a foundation for future work. These goals compete for budget. Agree on the priorities in writing so trade offs can be made quickly when they come up.

Upgrade, rebuild, or migrate?

Depending on the starting version, the realistic options range from a straightforward update to a full rebuild with content migration. Sometimes a different platform or a headless approach is worth evaluating. The right answer depends on your content, integrations, internal skills, and long term plans, not on which option sounds most modern.

Who will maintain it afterward?

Plan for life after launch. Decide who will apply security updates, who will handle editorial support, and how future enhancements will be requested and prioritized. Documentation and knowledge transfer should be part of the project scope, not an afterthought.

A practical next step

If several of these questions are hard to answer, a short assessment is usually the best investment you can make. It turns uncertainty into a plan with clear phases, realistic estimates, and known risks. Oak Street Group has worked with Drupal across many versions and can help you scope the work, whichever path you choose.