European Alternatives to Drupal

Why people leave Drupal

Drupal is a different kind of incumbent from most on this site. Nobody sells it to you. Drupal core is released under the GNU General Public License, the project's own About page says there are no licensing fees, and you run it on a server you choose. The people who leave it are therefore rarely leaving a price list or a contract. They are leaving a stack, a maintenance burden or a dependency on one place.

That place is drupal.org. The site where you download releases, find modules and read security advisories is operated by the Drupal Association, whose privacy policy names it as data controller at an address in Portland, Oregon, and says visitor information may be transferred to, stored and processed in the United States.

The GitHub repository is only a mirror: pull requests are not accepted there, and development happens on drupal.org. The Drupal trademark is registered to Dries Buytaert, not to the association.

None of this makes Drupal unsuitable for a European organisation, and we do not claim it does. The code is public and the licence cannot be withdrawn. The reasons to look elsewhere are narrower: you want a vendor or association under European law for the support relationship, you want a stack other than Drupal's PHP and its upgrade path, or you want a lighter system than the one your editors have been struggling with.

• The project infrastructure sits in the United States Drupal core is self-hosted, so your site data does not travel to Portland. What does is everything around it: the accounts of your developers on drupal.org, the issue queues, the module downloads and the security advisories. The privacy policy says that data may be processed in the United States. For a public body that audits its supply chain, that is a dependency worth writing down, even if it is a small one.
• Free software, paid agency time Drupal costs nothing to license, and the About page says so. The bill arrives as development and maintenance: a site is built by an agency, major versions are migrations rather than updates, and every contributed module is its own upgrade question. European systems such as TYPO3 and Ibexa have the same shape, but several here (Contao, Sulu, Wagtail) are smaller and easier to hold in one developer's head.
• You may not want Drupal's stack Drupal is a PHP system. A team that works in Symfony can pick Sulu or Ibexa. A Python team can pick Wagtail. A Microsoft shop can pick Umbraco or Kentico Xperience on .NET. Moving the CMS to match the language the rest of the company already writes is a common reason for a migration, and nothing about it is about Drupal being bad.
• Governance sits with a foundation and a person, not a company you can contract If something goes wrong with Drupal, there is no vendor to call. The Drupal Association supports the project as a non-profit, agencies sell the actual service, and the trademark belongs to an individual. A European vendor like Ibexa AS, Magnolia International Ltd or Kentico Software s.r.o. gives a procurement officer a legal entity, a contract and a register entry to point at.

What you have to replace, not just match

The first thing to replace is the content model. Drupal sites are built from content types, fields, taxonomies, views and blocks, configured in the admin interface and exported as configuration files. No European system copies that vocabulary. Ibexa and Sulu model content with their own page and content types, Wagtail models it in Python classes with StreamField blocks, and TYPO3 does it with its own page tree and content elements. Expect to rebuild the model, not import it.

The second is the module layer. Many Drupal sites depend on contributed modules for search, forms, SEO, media and workflow. Each needs a counterpart, either in the new system's core or as an extension, and the ecosystems differ in size.

Contao ships news, events and forms in the core. TYPO3 has a large extension repository. Sulu and Wagtail lean on the Symfony and Django ecosystems for the pieces they do not include. Make a list of every module you actually use before choosing.

Third come the people and the permissions. Editors who know Drupal's roles and workflows will have to learn new ones. TYPO3, Contao and Wagtail all offer permissions per page tree, and TYPO3 adds workspaces for approval, but the screens and the words are different. Plan a training day per editor group, and keep one person who understands both systems during the transition.

The alternatives compared

How each alternative compares to Drupal

What actually breaks when you switch

Content is the first thing to move. Drupal stores it in a database shaped by your own content types and fields, so an export is a script written for your site, not a button. Media files, URL aliases and taxonomy terms each need their own mapping, and redirects from the old paths must be tested page by page, or search traffic goes with them. Ask the agency which of these it will script and which it expects you to re-enter.

Contracts and people are the second. If an agency maintains your Drupal site, check the notice period before choosing a successor system. Editors will lose shortcuts they learned over years, and integrations to CRM, search or single sign-on have to be rebuilt against the new system's API. Run both sites in parallel until the redirects and forms are verified, and keep read access to the old one for a while.

Is Drupal itself a problem for GDPR?

Not in itself. Drupal core runs on your own infrastructure, so the data your site holds is under the same jurisdiction as your hosting provider, whichever country you pick. A Drupal site on a European host is as compliant as its operator makes it.

The part that touches the United States is drupal.org, where the Drupal Association is data controller and says information may be processed there. That concerns accounts and downloads on the project site, not the visitors to your own pages. If your organisation has a policy on tools your staff register for, this is the line to check.

Can I keep Drupal and still reduce the dependency?

Yes. Because the licence is the GPL, you can mirror releases, vendor your modules into your own repository and use a European agency for maintenance. For many organisations that is a smaller step than a migration and removes most of the practical dependency on drupal.org.

A migration makes sense when the stack, the editor experience or the cost of upgrades is the problem. If those are fine, staying and tightening your supply chain is a legitimate answer, and we would not push you off it.

Which one to pick

For a large public body or university with many sites, languages and editor roles, start with TYPO3. If your developers write Symfony and you want a vendor to contract with, compare Ibexa and Sulu. Python teams should look at Wagtail, and .NET teams at Umbraco or Kentico Xperience.

If your Drupal site is smaller than its reputation, Contao may be all you need. Pick Magnolia only when enterprise procurement wants a certified vendor and the budget exists. And if Drupal works, your agency is European and your editors are happy, staying is a perfectly good decision: the dependency on drupal.org can be managed without a migration.