We've worked with Drupal since 2010, starting with our first project for ENI. We build new sites and portals, take over and maintain existing ones, keep them evolving and move them to supported versions. Before we touch the code, we work out what's there and what's needed.
A Drupal portal built on solid foundations keeps growing for years, without being rebuilt. When the foundations don't hold, we rebuild it once, and from there it starts evolving again.
After a first call we gather your ideas and propose a roadmap: business and user goals, what goes into the first version and what stays out. The near stages are planned in detail, the later ones less so, and we refine them together in the first few weeks, telling you straight away where the uncertainties lie.
From there the work moves forward in milestones, usually monthly, each ending with a delivery you can see and try: the code in a test environment and its documentation. Every code change goes through a Continuous Integration and Delivery pipeline.
Once the portal goes into production, the longest part begins: adding features, updating Drupal and its modules, adapting it as the work of the people who use it changes. We work in cycles of about three weeks, two of development and testing and then the release to production, often without interrupting the service.
Drupal 7, 8 and 9 have reached end of life, and Drupal 10 is scheduled to reach it on 9 December 2026. After end of life a version gets no further releases, security releases included. We move your portal to a supported version, along a path that depends on where you're starting from.
When a portal comes to us from another supplier, the first step we suggest is an assessment: a full analysis of the portal before we change anything. From there we either grow it on its existing foundations or rebuild it.
Between 2024 and 2025 we looked after maintenance and ongoing development of a Drupal project for Fondimpresa, on foundations we had inherited. Since 2026 we've been maintaining the Rete civica, the civic portal of the Comune di Firenze (the City of Florence's administration), having already worked on part of its migration.
If your team develops in-house, we can work alongside it: we analyse a problem, an architecture or a technical choice and suggest how to proceed. You can ask us even if we're not already working together.
As the official Drupal release schedule shows, every version has an end-of-life date, after which it gets no further releases. From Drupal 8 onwards you upgrade one major version at a time: for example from 9 to 10, then from 10 to 11.
Drupal 8 changed the CMS's foundations: the core is built on Symfony components, themes use the Twig template engine instead of the previous system, and configuration lives in files that can be exported and versioned along with the code. That's why there's no upgrade from Drupal 7: content and configuration are migrated to a new portal and the theme is rebuilt. It's a re-engineering project, and it's worth designing it so that frontend and content can be separated, should you ever need to.
Here you upgrade without migrating content, moving from one version to the next until you reach a supported one. The work mostly involves custom code, contributed modules and the theme.
Drupal 12 is due out the same week, and after 9 December Drupal 10 will get no new releases. If your portal runs on Drupal 10, now is the time to plan the move: how much work it takes depends on the portal, and we estimate it once we've checked it.
45 minutes, free of charge, with the people who will work on your portal. We talk about what's holding you back today and what you want to achieve: you come away with a first idea of how ready your portal is and what needs checking.
Two weeks of analysis, without touching the code. We review the custom code, the contributed modules, how the repository is organised, any non-standard changes to the database, and the theme. At the end you get a list of blockers and a traffic light: green means we can start, amber means a clean-up comes first, red means it's worth considering a rebuild. The document is yours to keep, even if you don't go ahead with us.
A first goal in production, chosen with you to fit your budget. It lets you decide with a real result in hand.
From there we move one goal at a time, at a pace that suits your work. Each milestone ends with a delivery, code and documentation, and with a release to production when the time is right.
In 2021 we started working with the Corpo Nazionale dei Vigili del Fuoco, Italy's national fire and rescue service, getting a new portal ready for go-live. In 2022 an assessment showed that rebuilding it was the better way to support growth: we rebuilt it on Drupal, keeping the design that had already been approved, and it has been online since 2024. Pages are built from blocks, and each local command runs its own minisite with its own editorial team. The theme follows the guidelines of AgID, Italy's agency for digital government, and we check it with MAUVE++, the validator from CNR-ISTI, part of CNR, Italy's National Research Council: the lab has given us access to it for our projects.
Flexform's first portal, built on Drupal, was online from 2016 to 2023. When digital became central to the company, Drupal stayed as the content source and the frontend moved to Next.js. Today a single installation runs seven languages, connects to PIM, CRM and product configurators, and gains new features for users and retailers every year.
In 2024 we rebuilt Feel Florence for the Comune di Firenze, after an initial review of the previous portal showed that rebuilding it was the better option. We also redesigned the interface for smartphones first, so that tourists can use the portal easily. Then we added synchronisation with the city's systems, and today the portal exposes its data via API to the Feel Florence mobile app.
We've developed twelve contributed modules on drupal.org, including Breadcrumb Manager and HTTP Client Manager, and we're credited on two security advisories, for Mosaik and Workflow. Between 2011 and 2017 we helped organise five editions of the Italian Drupal Day, and since 2025 we've been among the organisers of DrupalCamp Italy. The Page Delivery modules will be released as open source on drupal.org on 22 October, at DrupalCamp Italy 2026.
If the portal holds up but the frontend slows down every new feature, there's no need to rebuild from scratch. A Next.js frontend runs alongside Drupal on the same domain and replaces the theme one family of pages at a time, keeping the same URLs: this is the Strangler Fig Pattern. Editors keep working in Drupal, and you can stop at any step. It's the method we're applying, with the Page Delivery modules, to an enterprise portal of more than 50,000 pages. From there the frontend can be built on a Design System, and new applications can grow on the same foundations: that's the direction we take with the people who work with us.
Drupal is our main tool, but before we propose it we look at what the portal has to do and who will use it every day. Three cases from our work:
If your Drupal portal holds up and doesn't slow down the people who work on it, the most useful advice is often to leave it as it is and let it grow.
It depends on what the portal has to do. For a complex portal, with lots of content, several languages, editorial teams with different permissions and integrations with other systems, Drupal is the tool we would still choose today. We adopted it in 2010 because we were looking for an open source, modular CMS, suited to enterprise projects and able to support complex organisations, and that's still why we use it. If the content model is simple and the editorial team is small, a lighter tool may be enough: we'll tell you before we start.
Not always. With an assessment we check whether the foundations can support growth. If they can, we build on them. If they can't, it's better to rebuild once, as we did for the Vigili del Fuoco, Italy's national fire and rescue service, and then grow the portal on the new foundations.
We start with a two-week assessment, without touching the code: we review custom code, contributed modules, repository, database and theme. You get a document listing the blockers, with a proposal, and it's yours to keep even if you don't go ahead with us. Then we decide together whether to grow the portal or rebuild it.
Moving on from Drupal 7 takes a migration: content and configuration move to a new portal, and the theme is rebuilt. It's also the moment to decide what the frontend will be. If you might want to separate it from the content one day, it's worth designing the migration with that in mind.
Yes, on request: we work alongside your in-house team, analyse a problem or an architecture and suggest how to proceed. You don't need an ongoing project with us.
The portal doesn't depend on a single person. We work as one team, every milestone ends with its own documentation and, when needed, we work alongside your in-house team.
Let's talk about your Drupal portal with the people who'll design and build it