We have been working with Drupal since 2010, starting with our first project for ENI. We build new websites and portals, take over and maintain existing ones, develop them further and upgrade them to supported versions. Before we touch the code, we assess what’s there and what’s needed.
A monolithic Drupal site, with content and the theme within the same application, remains a sensible choice if you allow it room to grow. When the foundation can no longer cope, we rebuild it once, and from there it continues to evolve.
A monolithic Drupal site can continue to grow for years, provided that certain fundamentals are in place. Feel Florence, one of the examples listed further down, is a case in point.
A supported version receives regular updates, including security updates. If the end of life is approaching, it is advisable to plan the transition before adding new features.
Headings, text, images and dates are stored in separate fields, not in blocks of hand-coded HTML. This means the same content can be used to populate new pages or other channels, such as an app.
What is displayed on a page and to which users is determined in the Drupal configuration, not in the theme templates. This means the theme only controls the appearance and can be changed without rewriting the rules.
Following an initial call, we gather our ideas into several scope plans: each one defines the scope of an objective – that is, what users and the business need, and what will be included in the first version. This forms the basis of the proposal.
Once the project has been launched, we draw up the execution roadmap: more detailed than the scope plans, it immediately highlights any remaining uncertainties. We proceed in stages, usually on a monthly basis, with each milestone involving a delivery to a test environment: the code and its documentation. Every change to the code goes through a Continuous Integration and Delivery pipeline.
The longest phase in a portal’s life begins after it goes live: adding features, updating Drupal and its modules, and adapting it to changes in how its users work.
Whether the portal comes from another provider or was developed in-house, we start by listening to what you tell us and, where necessary, by carrying out an assessment – that is, a comprehensive analysis of the portal before taking any action. We then either build on the existing foundation or rebuild it from scratch. Between 2024 and 2025, we managed the maintenance and development of a Drupal project for Fondimpresa, building on the foundation we had inherited. Since 2026, we have been responsible for the maintenance of the City of Florence’s Civic Network, having previously worked on part of its migration.
Drupal 7, 8 and 9 have reached end-of-life. For Drupal 10, end-of-life is scheduled for 9 December 2026. Once a version reaches end-of-life, it no longer receives updates, including security updates. We’ll migrate your portal to a supported version, following a process that depends on your current version.
If your team carries out its own development, we can support them: we’ll analyse a problem, an architecture or a technical decision and suggest how to proceed. You can ask us for this even if we aren’t already working together.
Have a chat with the people who will be working on your portal: what’s holding you back at the moment, what your objectives are, and what the portal is like. We also need some information such as versions, environments and working methods.
Two weeks of analysis, without touching the code. We’ll review the bespoke code, the Contrib modules, how the repository is organised, and any non-standard modifications to the database and the theme. At the end, you’ll receive a list of blocking issues and a proposal. The document remains yours, even if you decide not to proceed with us. If the development project does not have defined milestone objectives, the assessment can be included in the maintenance contract.
Two weeks of development and testing, followed by the release to production, often without interrupting the service. Requests are received by email or via a request management tool and are discussed at progress meetings, or SALs, where you can see priorities and progress at intervals that depend on the project and the client. Milestones are used when the objectives are broader and more clearly defined.
With every production release, you will receive the release notes, including links to what has been released. The code, documentation and other deliverables are provided in accordance with the maintenance contract. We are working to make activity reports a standard part of every project.
Drupal, Monolitich, UX & UI , Continuous Integration, Operations
In 2024 we rebuilt the tourism portal of the Comune di Firenze, the City of Florence's administration, on Drupal. We redesigned its interface for smartphones first, so tourists can find their way around it easily. We check its accessibility with MAUVE++.
Drupal, Monolitich, Operations, Continuous Integration
In 2022 we started with an assessment, the analysis we use to check whether a portal can keep growing on its current foundations. It gave a red light, so we rebuilt the portal, keeping the previously approved design. It has been live since 2024.
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.
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 has fundamentally changed the CMS: its core is built on Symfony components, and themes use the Twig template engine instead of the previous system. The configuration is stored in files that can be exported and version-controlled alongside the code. This is why you don’t simply upgrade from Drupal 7: you migrate the content and configuration to a new portal and rebuild the theme. It’s a re-engineering process: it’s worth designing it from the outset to separate the front-end from the content, should you ever need to do so.
Here, you can update without migrating the content, moving from one version to the next until you reach the supported version. The work mainly concerns bespoke code, contrib modules and the theme.
Drupal 12 is due to be released that same week. After 9 December, there will be no further releases for Drupal 10. If your portal is running on Drupal 10, now is the time to plan the migration: the amount of work involved depends on the portal, so we will assess this once we have reviewed it.
On drupal.org we have developed contrib modules such as Breadcrumb Manager and HTTP Client Manager. We are also credited on two security advisories, for Mosaik and Workflow.
Between 2011 and 2017, we helped organise five editions of Drupal Day.
Since 2025 we have been among the organisers of DrupalCamp Italy, where on 22 October 2026 we released the Page Delivery suite as open source.
If your monolithic Drupal setup is holding up but the frontend slows down with every new feature, there’s no need to rebuild it from scratch. The frontend can be separated from Drupal one step at a time, whilst content editors carry on working as they do today. We explain when it’s worth doing this and how we go about it on the page about decoupled architectures.
Drupal is our main tool, but before we suggest it, we look at what the portal needs to do and who will be using it on a daily basis. Three examples from our work:
If your Drupal portal is holding up well and isn’t holding back those who work on it, the best advice is often to leave it as it is and let it grow.
It depends on what the portal needs to do. For a complex portal with a lot of content, multiple 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 capable of supporting complex organisations: we still use it for that reason. If the content model is simple and the editorial team is small, a lighter-weight tool may suffice: we’ll let you know before we start.
Not always. We carry out an assessment to check whether the existing infrastructure can support the growth. If it can, we develop it further. If it cannot, it is better to rebuild it from scratch, as we did for the Fire Service. The portal then grows on the new infrastructure.
Let’s start with what you tell us and some information about the portal: versions, environments and how it’s currently run. Where necessary, we’ll carry out a two-week assessment – without touching the code – to check the bespoke code, Contrib modules, repository, database and theme. This results in a document outlining any blocking issues and a proposal, which remains yours even if you decide not to proceed with us. We’ll then decide together whether to scale up the portal or rebuild it.
A migration is required from Drupal 7: content and configuration will be moved to a new portal, with a rebuilt theme. This is also the time to decide what the front-end will look like. If you ever want to separate it from the content, it’s best to design the migration so that it’s already set up to do so.
Yes, on request: we’ll work alongside your in-house team, analyse a problem or an architecture, and suggest how to proceed. You don’t need to have an ongoing project with us.
The portal does not rely on any one person. We work as a single team; each milestone is completed with its own documentation and, where necessary, we support your in-house team.
Let's talk about your project with the people who will design it