A decoupled architecture separates content from the frontend, the part of the portal that visitors see: content stays in Drupal or another CMS, while a Next.js frontend renders the pages. It pays off when the frontend is slowing your portal down. You can start from a new project or from a monolithic Drupal portal already in production, which moves to decoupled in stages without taking the site offline. When decoupled isn't needed, we'll tell you before we start.
With a decoupled architecture, the frontend can be rebuilt or improved without touching your content or your editorial team's work. A frontend-only change is released without touching the backend, the part that manages content and rules. The portal doesn't have to be rebuilt every few years: it grows on the same foundations.
The Flexform case study below is an example: the portal has been live since late November 2023 and evolves every year.
In a monolith, content management, logic and presentation live in the same application. With Drupal, that means content and theme in the same codebase. It isn't a flaw in itself: many portals work well this way. The portal we rebuilt for the Corpo Nazionale dei Vigili del Fuoco, Italy's national fire and rescue service, online since 2024, is a monolithic Drupal portal.
Decoupled means backend and frontend are separate and communicate through a contract: precise rules on which data passes from one to the other, and in what form. In the progressive version, Drupal still generates the pages and a JavaScript framework handles only some parts.
A separate frontend, Next.js in our case, renders all the pages it is responsible for. Content is created and managed in the CMS, Drupal or another one, where the editorial team keeps working.
It's a CMS that doesn't produce pages: it exposes its content to one or more frontends only through APIs, the interfaces a frontend queries. Decoupled and headless aren't synonyms: Drupal produces pages by default, but it can be used in a decoupled way.
A landing page, a restyle or a new section all touch the site's theme, so even a small change becomes a project.
A change in one part of the portal breaks something somewhere else.
It keeps being put off, because everything would need redoing anyway.
TTFB and LCP, the server's response time and the time it takes for the main content to appear, hurt the experience. Improving them without changing the architecture seems impossible.
Your team would like to work with React, but the CMS theme doesn't allow it.
Over the years different people have worked on it, and nobody is quite sure what happens when you touch something.
When the portal is yet to be built, the choice of CMS comes from the project. Drupal remains our technical core, but it isn't the only route: for Vivo Concerti we chose Strapi, a lighter CMS better suited to their editorial team's work, with a Next.js frontend. We assess other platforms case by case, according to the technologies and skills we have. If a platform is outside our skills, we'll tell you straight away.
We start with a call and one or more scope plans, each setting out the boundaries of one objective: what users and the business need, what is included and what isn't. Together they give a first projection, only loosely binding because it comes before the technical analysis, and the proposal follows from it. Once the project has started we write the execution roadmap, which is more precise than the scope plans. It is detailed on the nearest milestones and less so on the distant ones, which are defined as we go in the light of what happens in the project. We work in milestones, usually monthly.
The same path applies if your portal is on Drupal 7, which has been out of support since 5 January 2025. It can't act as the backend for a new frontend, so it needs to be redesigned. The new portal is built ready to be decoupled from the start.
If your portal runs on monolithic Drupal in production, you don't need to rebuild it from scratch to decouple it. A full rewrite halts the business for months and concentrates all the risk in a single release night. We use the Strangler Fig Pattern instead, an incremental replacement strategy in which the new system sits alongside the old one and takes over its functions one at a time.
Here, a Next.js frontend runs alongside Drupal on the same domain and takes over the portal one family of pages at a time, meaning a group of pages of the same type, with the same URLs. We call it incremental migration, but it is the pages that move to Next.js, not the data: the content stays in Drupal.
Each family goes over only after eight checks signed off by a person. If needed, it can be moved back to Drupal with a configuration change, without a new code release. We are applying the method to a portal of more than 50,000 pages.
Page Delivery is the suite of Drupal modules, developed by bmeme, that incremental migration relies on. Drupal serves the whole page as JSON, content included, which Next.js interprets and renders. JSON:API and GraphQL are used to request data, and they work alongside Page Delivery.
The modules will be released as open source on drupal.org on 22 October, at DrupalCamp Italy 2026 in Bologna, where their maintainer, Adriano Cori, will present the method in a talk.
Layout, Composition, Route Ownership and Authentication. Together they make the same address return HTML to the browser and the whole page as JSON, content included, to the new frontend. Drupal decides which paths move over to Next.js.
Every portal has its own sources, such as views, blocks, menus and archives. A project adapter translates them into the modules' format. That is the bespoke work: you pay for that, not for a licence.
The modules will be open source and every milestone ends with technical documentation. The adapter's code remains yours and, if you have an in-house team, we work alongside them until they can carry on by themselves.
The move makes sense if you have a modern Drupal with structured content where the theme is the bottleneck. It also makes sense if you want a Next.js frontend with its own team and releases without migrating data, or if editors need to keep composing pages in Drupal. An app or other channels to feed are not an obstacle, because JSON:API and GraphQL work alongside Page Delivery.
It doesn't make sense if the content model needs rethinking anyway, or if the frontend has to be the one deciding how a page is composed. Nor does it make sense if the theme isn't a bottleneck, or if the site is so small that maintaining two systems costs more than it returns. If the portal is on Drupal 7, it first needs re-engineering, as for a new project.
Sometimes the move is possible, but not straight away. If the logic of the pages is scattered through the theme, or there are fragile custom modules and outdated versions, these get fixed first. That is why we start with an assessment, the full analysis of the portal before we step in.
Areas behind a login stay on Drupal, at least at first, because the public frontend doesn't handle visitor authentication. Maintaining Drupal and the new frontend side by side for a period has a cost, because you need skills in both. That is why we work in milestones, with a defined end.
Editors keep using Drupal as they do today, with the same editing interface, the same publishing workflows and the same permissions. The rules on what appears on a page stay configured in Drupal.
URLs, canonical tags and hreflang tags stay the same, redirects are 301 or 308 with no chains, and the sitemap is always generated by Drupal. Technical parity between old and new pages is a condition for moving further sections over. We don't promise rankings: we make sure we don't break what works today.
During the move and the releases we preserve the tracking already in place. In the frontend we implement the requirements given to us by whoever looks after your marketing.
Forty-five minutes, free of charge, with the people who design the project, not a salesperson. We talk about your portal, what is blocking you today and your goals. You leave with a first idea of how ready the portal is and what needs checking. We also give you the order of magnitude of the investment.
Two weeks of paid analysis and documentation, without touching the code. We hand over the list of blockers with the actions to resolve them, a pilot proposal calibrated to your budget, and a green, amber or red traffic light that says whether and how to start. The document remains yours even if you don't carry on with us.
A family of pages goes into production on Next.js, chosen with you according to your budget: it can even be a set of simpler pages. The first family usually reaches production in two to three months, so you see a real result before deciding on the rest.
One family of pages at a time, at the pace of your business. The first milestones are the most demanding, because that is when the release pipeline, the components, the adapter and the procedures are built. Later ones reuse what is already there, and the cost of each new section goes down.
A new frontend, whether it comes from a new project or from moving a monolith over, needs a system of components. The next step can be a Design System, meaning the interface components gathered in a single system that lives in the code. On this base you rethink the experience, build further applications consistent with the portal, and the interfaces evolve without accumulating differences between design and code.
Drupal, Next.js, Decoupled, Continuous Integration
In 2022 digital was becoming central to Flexform's work, and the portal needed new tools. The choice: content on Drupal, with the frontend rebuilt in Next.js. Since 2023 the portal has grown every year, with new features for users and retailers.
Strapi, Next.js, Decoupled, Continuous Integration, UX & UI
We're Drupal specialists, and for Vivo Concerti we advised against it: their editorial team needed a lighter CMS that suited its work. Strapi manages the content, while Next.js, running separately, renders the pages and handles the high traffic.
No. Decoupled means that backend and frontend are separate and communicate through a contract. A headless CMS doesn't produce pages: it exposes content only through APIs. Drupal produces pages by default, and we use it in a decoupled way, with a Next.js frontend that renders the pages while Drupal remains the source of the content.
The main advantage is being able to change the frontend without touching content or the editorial team's work. If you move a monolithic Drupal to decoupled, the cost is coexistence: for a period you maintain Drupal and the new frontend side by side.
If the portal is a monolithic Drupal, you don't have to rebuild everything. With the Strangler Fig Pattern, a new Next.js frontend runs alongside Drupal on the same domain and takes over one family of pages at a time, with the same URLs. You can stop whenever you like: the sections already moved work, and the others stay on Drupal.
When a monolithic Drupal moves to decoupled, URLs, canonical tags, hreflang tags and the sitemap stay the same. Redirects are 301 or 308 with no chains, and we preserve the tracking already in place. If parity on these points is missing, the section stays on Drupal. We don't promise rankings.
It depends on where you start. If you move a monolithic Drupal to decoupled, the first family of pages usually reaches production in two to three months. We give you the order of magnitude of the investment in the introductory call, which is free and lasts 45 minutes, while the precise estimate comes with the assessment, which lasts two weeks and is chargeable. You don't have to approve a year-long project to begin: you start with a single section and decide the rest after seeing the results. In a new project, the scope plans give a first projection, which becomes more precise after the start with the execution roadmap.
When an editor publishes, Drupal sends the frontend a notification signed with HMAC, which marks as stale only the data affected. The next visitor immediately receives the cached version, while the updated one is regenerated in the background. Pages are generated on first access and then stay in cache, so build time doesn't grow with the number of pages. If Drupal doesn't respond, what to show is decided in advance for each function: the last cached version, a version without dynamic parts, or an unavailability message.
No. JSON:API and GraphQL let the frontend request data, entities and fields, from which it then composes the page. With Page Delivery the frontend requests the whole page instead: Drupal composes it as it does for HTML, and Next.js interprets and renders it. The two approaches work alongside each other, so an app or other channels to feed can keep using JSON:API or GraphQL.
Let's talk about what is holding your portal back, with whoever will design it