Niels de Feyter: Why Drupal 7 Upgrades Need More Than a Migration Plan

For many organisations still running Drupal 7, the challenge is no longer whether to upgrade, but how to modernise without disrupting systems that have often supported years of content, workflows, and business operations.

Upgrade projects frequently combine platform migration with redesigns, new features, and architectural changes, increasing complexity and making it harder to verify whether critical functionality still works as expected.

Niels de Feyter, founder and lead developer of CodeLift, argues that successful Drupal upgrades depend on preserving a system's observable behaviour while modernising its underlying platform. Drawing on more than 15 years of experience in Drupal development and migrations, he has built his work around what he calls the "Steady State Update" principle.

The idea emerged from a pattern he observed across software projects: changing both the implementation and the user-facing behaviour of a system simultaneously often makes verification more difficult and increases the risk of regressions.

In this written interview, Niels discusses why organisations remain on Drupal 7 in 2026, the operational and security risks associated with ageing systems, and the challenges of preserving business-critical functionality during large-scale upgrades.

He also shares his views on verification, testing, migration complexity, AI-assisted development, and what defines a successful Drupal modernisation project. He shared his insights with Kazima Abbas, sub-editor at The DropTimes.

TDT [1]: Your work now centres on Drupal 7 to modern Drupal upgrades. What repeated failure pattern in traditional upgrade or rebuild projects led you to build CodeLift?

Niels de Feyter: Software development teams should not change the inside and outside of a system at the same time. It makes it difficult to prove that a system works correctly, requires more effort to control the process and introduces waste in the form of regressions and waiting time.

This insight led to CodeLift's "Steady State Update" principle and me founding the company in 2024. Keep the outside of the system the same while improving and modernising the inside. And prove that the system works, by proving that the observable state is the same.

With this approach, I know it is possible to modernise every legacy system without breaking things.

TDT [2]: Drupal 7 sites are still being upgraded in 2026. From the projects you see directly, what keeps organisations on Drupal 7 this late, what risks increase the longer they wait, and when does the age of the underlying PHP or server environment make a steady-state upgrade harder to deliver?

Niels de Feyter: Typically, site owners are happy with their Drupal 7 system because it has served them well for many years. The technical and operational risks accumulate beneath the surface, but they're hidden. The more legacy a system is, the more effort it takes to modernise it.

This happened over the last couple of months across various large websites internationally. Probably done with the same AI tools that are available to any developer worldwide.

TDT [3]: Drupal 7 upgrades are often described as technical migrations involving content, functionality, and architecture. In real projects, where does that description become misleading?

Niels de Feyter: Drupal 7 upgrades are not only technical migrations. We see that capturing what the system does and how it is used is an essential part of a project. And that this can only be done in close collaboration with the site-owner's team. This non-technical effort is significant: identifying hidden logic, testing real workflows, validating critical behaviour, and approving what should remain.

With a Steady-State-Update, we do minimise the client's time investment, although it will still be significant for Drupal 7 upgrades.

TDT [4]: Many Drupal 7 sites have accumulated years of custom modules, editorial workflows, permissions, content types, and undocumented business rules. How do you determine what must be preserved, rebuilt, retired, or questioned?

Niels de Feyter: As a general rule, we preserve everything. Unless the client tells us early on to drop a certain part of the website.

TDT [5]: When you say “verification-first,” what exactly is being verified? Walk through one upgrade step from capture to comparison to acceptance.

Niels de Feyter: The observable state of a system. Our verification system visits a webpage as a logged-in user. It will create a screenshot in both the new and legacy systems. The screenshots must match. And if it doesn't match, we know there is a bug.

Now scale this up to multiple users and a full sitemap, and a single verification run will compare 1000 pages or more. It also supports multistep workflows, such as a product configurator that places a configured product in a shopping cart.

We have a quality assurance team that performs manual testing as well. They are responsible for verifying things like outgoing e-mail, sign-ups, reCAPTCHA, and other non-automated processes.

Our quality assurance team gives the final verification verdict.

TDT [6]: Your steady-state upgrade approach depends on proving that the site behaves the same before and after the upgrade. What parts of a Drupal 7 site can be reliably captured, and what parts remain difficult to verify automatically?

Niels de Feyter: A difficult case is the hidden business logic of a system. Specifically, in custom code and modules that are not ported to modern Drupal (such as Rules). A webshop might have a pricing calculation that applies discounts based on roles and country-specific conditions. It is crucial to know how to trigger all the different pricing calculations.

The easiest is everything that is directly visible on a webpage, or in a REST response to an HTTP GET request. For example, viewing a front page as a logged-in user. This verification is fully automated, and the discovery of these pages is as well.

Manual testing is necessary for workflows with external systems. For example, a signup with reCAPTCHA security and an HTML email that must be received in the visitor's email client.

TDT [7]: How do you handle legacy data problems, such as broken entities, inconsistent field values, abandoned content types, or database assumptions that only appear when migration scripts run?

Niels de Feyter: In almost all projects, we consolidate the Drupal architecture to modern standards. This includes:

• Entity, field and translation data model
• Authentication and authorization system
• Caching and page speed optimization

The realisation of the data migration is an iterative ETL process, where we run the migration, verify the outcome and then fix & repeat until it works.

This way of working allows us to load data from the legacy system into the new system in the optimal format and structure.

TDT [8]: What does a strong “definition of done” look like for a Drupal 7 upgrade? Who defines it, and how do you prevent that definition from changing halfway through the project?

Niels de Feyter: A project is done when the modernised system runs in production without issues for one month. At that point, we expect that all functionality has been touched, and this proves the success.

A strong "definition of done" would also include a specification of a system's visible behaviour and the implementation layer it is using.

Each project starts with a discovery phase with the exact goal of discovering this specification.

In reality, what did occur was that during manual testing by our clients, hidden business logic and external system integrations were discovered. Our goal is to move discovery as far forward as possible with automation.

TDT [9]: Where do clients usually underestimate Drupal 7 upgrades? Where do agencies usually underestimate them when estimating scope, timeline, and delivery risk?

Niels de Feyter: Usually, what's underestimated is the amount of testing that is required in a single test run and the total number of iterations until final approval. This quickly adds up. Imagine an end-to-end test takes 10 hours, but it was estimated as 5 hours. And that instead of 5 iterations, 25 were actually needed. The difference is a factor of 10 (5x5 versus 10x25). I personally think that only automation and reuse of the integrated tooling between projects is a good solution for this.

A second underestimation is the data migration. The Drupal migration module is a complex system that tends to break when many plugins and dependencies are combined. We write additional scripted data-migration code to enhance and workaround the Drupal migration module.

TDT [10]: How does CodeLift change the developer workflow compared with a rebuild-driven approach? What becomes faster, what becomes stricter, and what still requires human judgment?

Niels de Feyter: CodeLift's steady-state update will give you significant gain in excess of creative teamwork, like meetings to prioritise and rethink systems. This is still possible, but scoped in a different project and not within the Drupal 7 upgrade. We notice that this unblocks the developer workflow by reducing waiting time for input or approval from external stakeholders.

Human judgment is still needed for software architecture.

TDT [11]: AI tools are increasingly used in development workflows. In Drupal 7 upgrade work, where can AI realistically help today, and where does it introduce risk or false confidence?

Niels de Feyter: Especially since Claude Code entered the scene in 2025, writing code and framework development like Drupal has become way easier. We use it all the time. A tricky thing is that because writing code is now apparently easy, it is also easy to introduce bugs or unmaintainable features. Verification and review are, therefore, more important.

Funny enough, I also observed this when Drupal entered the scene in 2010. It allowed way more people, me included, to build complex websites while earlier tools were too difficult (like plain PHP or Java). But alongside this ability, a new profession emerged. I expect the same thing will happen with AI agentic coding. Software still is and will always be an engineering problem.

TDT [12]: For teams planning a Drupal 7 upgrade now, how should they decide between Drupal 10 and Drupal 11? What factors matter most for long-term maintainability, contrib readiness, and project risk?

Niels de Feyter: Every Drupal site should upgrade to Drupal 11 in 2026. Drupal 10 will reach end of life on December 9, 2026.