01
Unambiguous resolution
Drupal identifies route, language, entity, theme and page family without ambiguity.
Incremental migration with the Strangler Fig Pattern: decoupling Drupal without stopping the business
Rebuilding a Drupal portal from scratch takes months before it starts to deliver value, and concentrates all the risk into a single night’s release. With the Strangler Fig Pattern, a new Next.js frontend runs alongside Drupal on the same domain and replaces its theme section by section.
By the bmeme team
- Adriano CoriSoftware Engineer
The full method in a 21-page white paper
The white paper is free and needs no registration. If you make decisions, ten minutes are enough; if you design, you'll find the architectural choices, the eight checks and, in the PDF only, an eight-question self-assessment to complete with your team. The PDF is for reading and printing; this page is the web version.
What is the Strangler Fig Pattern applied to Drupal?
The Strangler Fig Pattern is an incremental migration strategy: a new system replaces the existing one piece by piece, while the old one keeps running. When applied to Drupal, this means adding a Next.js frontend to the portal under the same domain, which replaces the portal’s theme one family of pages at a time: for example, all product pages, or all news items.
The name comes from the strangler fig, a plant that grows around a host tree until it replaces it. Martin Fowler used it to describe this kind of migration.
In our case Drupal doesn't go away. It remains the single source of content and your editors' everyday tool: what gets replaced, section by section, is its theme. The result is a decoupled Drupal architecture: on the migrated pages, when only the frontend changes, the backend remains unaffected.
When does it make sense to decouple a Drupal portal?
When the frontend has become the bottleneck for your business. If you recognized yourself in at least two of these points, keep reading. If you didn't recognize yourself in any of them, you probably don't need decoupling today. That's okay.
Every new initiative takes weeks
A landing page, a restyle or a new section touches the Drupal theme, and timelines stretch.
Releases are scary
A change in one place breaks something somewhere else.
The redesign is stuck
It stays on hold because "everything would need rebuilding anyway".
Performance holds you back
TTFB and LCP hurt the experience, and improving them without touching the monolith seems impossible.
Your team wants to work in React
Your frontend team would like to use React, but the Drupal theme doesn't allow it.
Nobody really knows the site anymore
It has grown over the years through many hands, and no one is sure what happens if you touch something.
Why is rebuilding everything from scratch the wrong bet?
Because it concentrates all the risk at the worst possible moment. A full rewrite takes months before it delivers value: meanwhile the business waits, requirements change and the new system chases a moving target.
At go-live, all the accumulated risk hits at once: data, features, integrations, indexing. If something goes wrong, going back means throwing away months of work.
With an incremental migration the risk doesn't disappear. It is split into many small releases, each reversible on its own.
What changes during the migration?
During the transition some pages are still served by Drupal, as today, and some by Next.js. Sections move to the new frontend one at a time, when they are ready, and URLs stay the same.
In this phase Drupal has two roles: it serves the pages not yet migrated and provides the new frontend with the migrated pages, content included.
For editors
Nothing new to learn: same admin, same publishing workflows, same permissions. The rules about what appears on a page stay in Drupal and apply to both old and new pages.
For the business
Start with a single section and decide the rest once you've seen the results: no need to approve a year-long project. You can stop whenever you want, and the site keeps bringing in traffic and leads while we work.
For search engines
Same URLs and canonicals, sitemap always generated by Drupal, redirects without chains. We guarantee technical parity between old and new pages. We don't promise rankings: we make sure we don't break what works today.
How do Drupal and Next.js coexist on the same domain?
They split the pages between them without visitors noticing. Every request goes through an Nginx proxy extended with Lua, which reads the map of migrated routes from a dedicated Redis instance and decides who responds. If the traffic-routing layer has a problem, everything falls back to Drupal.
The four design choices
Drupal remains the single source of truth
Content, taxonomies, visibility rules and layout configuration live only in Drupal. The frontend doesn't duplicate data or rebuild rules: it receives fully resolved pages and renders them.
Next.js runs stateless
The new frontend renders pages on the server (SSR with the App Router) and doesn't manage visitor sessions. The browser never talks to Drupal directly: every request goes through the Next.js server, following the Backend for Frontend pattern.
Traffic is routed at the edge
The decision on who responds never touches Drupal, so it doesn't add to Time to First Byte (TTFB). If Redis doesn't respond, the request goes to Drupal: when in doubt, the site works as before.
Same URL, two formats
The same address returns the same page: as HTML to the browser and as JSON to the frontend, based on the Accept header. Page Delivery will not add parallel APIs with their own paths.
For technical teams
The Redis map is a projection that can be rebuilt from Drupal, not an authoritative source. A Next.js error doesn't automatically fall back to Drupal: which system serves a route is an explicit decision, not a side effect, and this avoids inconsistent behavior towards crawlers. The same page is requested in two ways: the browser sends Accept: text/html, the Next.js server sends Accept: application/vnd.drupal.page-composition+json.
How do you decide when a section moves to Next.js?
02
Structure ready
The required layout variant exists in the new frontend.
03
Components covered
Every block that can appear on the page has its own validated React component.
04
Compatible regions
The regions produced by Drupal are supported by the target variant.
05
Same access, same order
Visibility, ordering and contextual rules match the current page.
06
Variables declared
Parameters and language variants that change the page are listed explicitly.
07
Cache defined
Cache tags and update rules for the route are set.
08
Test passed
Functional and visual tests compare the current page with the new one on sample routes.
The contract
No section switches systems by mistake: every move is checked, approved by a technical lead and reversible. The checks rely on a contract. Drupal returns the whole page as JSON split into five regions (beforeMain, navigation, main, aside, afterMain): each region lists its components in order, with their content. The frontend receives the page already resolved, with no HTML markup, and renders it with known, validated React components. If an unknown component arrives, or data that doesn’t match the schema, the page is never published half-done: the error is explicit and visible in the logs.
If a check is missing, the section stays on Drupal. That's not a failure: it's what makes the migration safe. And going back is a configuration change, with no new code release.
How does content stay fresh and releases reliable?
Published content appears right away and releases don't get longer as the site grows. If a release degrades performance, it rolls back automatically.
Event-driven updates
When an editor publishes, Drupal sends Next.js an HMAC-signed notification that marks only the affected data as stale. The next visitor immediately gets the cached version while the updated one regenerates in the background (stale-while-revalidate). Route changes follow the Outbox Pattern, so no change is lost halfway.
If Drupal doesn't respond
A circuit breaker stops hammering a struggling backend. For each feature you decide in advance what to show: the last cached version, a version without dynamic parts, or an explicit unavailability message.
Constant build time, Blue/Green releases
The Next.js build doesn't call Drupal (Zero Build-Time Fetching): whether the portal has a thousand pages or a hundred thousand, the pipeline takes the same time. Each release goes to a twin environment and, if TTFB, LCP or error rate exceed thresholds, traffic automatically returns to the previous one.
For technical teams
Cache tags are declared before the fetch, from known identifiers. The X-Drupal-Cache-Tags header is not an alternative: it is a diagnostic header and stays disabled in production. On complex pages it lists hundreds of tags, makes every response heavier and can exceed the header size limits of proxies and CDNs. It would arrive too late anyway: by the time you read the response, the fetch is already cached without tags.
What doesn't the Strangler Fig Pattern solve?
Coexistence has a cost
For a while, you’ll be running two stacks, and you’ll need expertise in both Drupal and React. That’s why the migration is planned in milestones, with a defined end point. If you stop before then, the migrated sections will remain on Next.js and the others on Drupal.
Not everything migrates right away
The most complex or layered sections stay on Drupal until their components are mapped. It's a deliberate choice.
Blue/Green has a delicate window
If editors change content while a release is being prepared, a brief misalignment can occur. It's handled with a reconciliation before the switch or a temporary write freeze.
Restricted areas are a separate matter
The public frontend doesn't handle visitor logins: areas that require authentication stay on Drupal, at least at first.
The Strangler Fig reduces risk, but doesn't eliminate it. And the starting point matters: presentation logic scattered in the theme, fragile custom modules or outdated versions need fixing first. That's why we always start with an assessment.
Still on Drupal 7?
The Strangler Fig Pattern assumes a modern Drupal acting as the backend for the new frontend. Drupal 7 has been out of support since January 2025 and can't host the Page Delivery modules. In your case you need a re-engineering, and the upgrade assessment is where we design a new platform that is ready for decoupling from day one.
What is Page Delivery?
Page Delivery is the suite of Drupal modules we use to apply the method. The Page Delivery modules will be released as open source on drupal.org on 22 October, at DrupalCamp Italy 2026, under the GPL. They will coexist with the APIs already in Drupal, including JSON:API and GraphQL. The tools will be free and public. The custom part is the project adapter, which translates your portal's sources (views, blocks, menus, archives) into the Page Composition contract. You pay for the work on the adapter.
The four Page Delivery modules
Page Delivery Layout
Defines logical layouts and maps Drupal theme regions to contract regions.
Page Delivery Composition
Returns the whole page as JSON, content included, on the same URL as the HTML version, based on the Accept header.
Page Delivery Route Ownership
Defines which paths move to Next.js, by exact match or by prefix, and publishes the routing map to Redis. Drupal remains the default.
Page Delivery Authentication
When enabled, it protects the JSON of your pages. The request comes from the Next.js server, which authenticates against Drupal with one of the authentication providers already in place. That way the JSON of your pages can be read only by your frontend, not by just anyone.
How do you get started, and how long does it take?
01
Discovery call, free, 45 minutes
We talk about your portal, what's blocking you today and your goals. You come away with a first idea of how ready the site is and what needs checking.
02
Assessment, paid, 2 weeks
It's analysis and documentation: we don't touch the code. You get the list of blockers with the actions to fix them, a pilot proposal sized to your budget and a traffic light that tells you whether and how you can start. The document is yours, even if you decide not to continue with us.
03
Pilot
One family of pages goes live on Next.js. We choose it with you based on your budget, and it can also be a set of simpler routes. You see a real result and decide with data in hand.
04
Milestone-based rollout
One family of pages at a time, at your business's pace. The first milestones are the most demanding; from then on we reuse what's already there, and the cost of each new section goes down.
Assessment outcomes: green, yellow, red
Green · Compliant code
Solid architecture, standard Drupal database, no critical code. You start on the expected time and budget.
Yellow · Technical debt
Some non-standard parts need cleaning up before starting. The cleanup is estimated separately.
Red · Incompatibility
Unstable or non-upgradable system, data altered by external systems or undocumented code. We stop and assess a rebuild.
The first family of pages usually goes live in 2–3 months. We give you the order of magnitude of the investment in the discovery call, and a precise estimate with the assessment.
Who is behind the method?
bmeme is a twelve-person Digital Tech Boutique that designs and builds Drupal and web architectures, from requirements analysis to maintenance. We are small by choice: you sit at the same table as the people who design the architecture and write the code, with no intermediaries. Some of our team have been working with Drupal since 2009.
Since 2022 we have been shipping high-traffic decoupled portals to production, with or without Drupal, including migrations from monolithic to decoupled Drupal done without blocking the site. Page Delivery grew out of that work: we generalized what we had built for specific cases. Today we are applying the method to a portal with more than 50,000 pages.
Your portal doesn't depend on us: the modules will be open source, the adapter code is yours and every milestone ends with technical documentation. If you have an in-house team, we work alongside it until it can carry on alone.
Frequently asked questions about incremental Drupal migration
How long does an incremental migration of a Drupal portal take?
The first family of pages usually goes live in 2–3 months. The overall duration depends on how many sections you want to migrate and on the pace of your business, because the migration is planned in milestones, with a defined end.
How much does it cost?
There is no price list: we give you the order of magnitude in the discovery call and a precise estimate with the assessment. The Page Delivery modules will be free, so you only pay for the work on your portal. The cost of each new section goes down with reuse.
Do editors have to change tools?
No. They keep using Drupal with the same admin, the same publishing workflows and the same permissions, for both migrated and non-migrated pages.
Does the migration put search rankings at risk?
We guarantee technical parity between old and new pages: same URLs, canonicals, hreflang and structured data, sitemap generated by Drupal, redirects without chains. We don't promise rankings, but parity on these points is a condition for extending the migration to new sections.
Can it be applied to a Drupal 7 site?
Not directly. Drupal 7 has been out of support since January 2025 and can't host the Page Delivery modules: it needs a re-engineering, which we design to be ready for decoupling from the start.
Can I stop halfway?
Yes. Migrated sections keep running on Next.js, the others stay on Drupal, and any section can go back to Drupal with a configuration change.
Can our in-house team carry on alone?
Yes. The modules will be open source, the adapter code is yours and every milestone ends with technical documentation. You need skills in both Drupal and React, and we work alongside your team until it's autonomous.
Can restricted areas with login be migrated?
At least at first, they stay on Drupal. The public frontend doesn't handle visitor authentication, so restricted areas are assessed separately.
When is Page Delivery a good fit, and when isn’t it?
It’s a good fit if you have a modern Drupal with structured content and the theme is what’s holding you back; if you want a Next.js frontend with its own team and releases, without migrating your data; if your editors need to keep composing pages in Drupal. It isn’t a good fit if the content model needs rethinking anyway, if the frontend should decide how a page is composed, if you’re on Drupal 7, if the theme isn’t holding you back, or if the site is so small that two systems cost more than they return. An app or other channels to feed aren’t an obstacle: JSON:API and GraphQL remain available.
Why not JSON:API or GraphQL?
Because the two approaches answer different questions. With JSON:API and GraphQL the frontend asks for the data it needs, entities and fields, and builds the page. With Page Delivery the frontend will ask for the page: Drupal composes it, as it does for HTML, Next.js interprets and renders it. You don’t have to choose: Page Delivery will coexist with JSON:API and GraphQL.
To find out whether the method suits your portal, let's talk: the discovery call is free and lasts 45 minutes.
We’re gonna dive deep this architecture at DrupalCamp Italy 2026
On 22 October in Bologna, from 17:05 to 17:45, Adriano Cori, Software Engineer at bmeme, presents the talk «Evoluzione Enterprise senza "Big Bang": lo Strangler Fig Pattern con Drupal». At the same event we will release the Page Delivery modules as open source.