Why moving from Headless to LocalGov Drupal is the best decision you've made in years

There's a specific kind of suffering that only a developer who's worked on a headless CMS setup truly understands. The pitch sounds incredible: decouple your content layer from your presentation layer, give your editors a clean CMS, and let your front-end team build something fast and modern in React. Beautiful in theory. An absolute crime scene in practice.

That was Hackney Council's website. A headless WordPress back-end with a React front-end. Flexible. Modern. Thoroughly miserable to work on. I often found myself screaming into my Nicolas Cage cushion.

The problems aren't always obvious at first. You launch the thing. It's fast. The Lighthouse score is great. Everyone feels quite clever. Then six months pass. A content editor needs to preview a page before publishing. You realise your preview pipeline involves three services, two environment variables, a custom serverless function, and the kind of incantation that only one developer on the team actually understands. That developer has since left.

This is not a uniquely Hackney problem. It's a problem that plays out at councils, startups, and enterprises alike whenever someone mistakes "decoupled" for "simpler." Essex County Council went through the same thing. They replatformed to Contentful in 2019, chose a modern decoupled approach, and it worked. Until it didn't. The content management system was fine, but the bespoke React front end became a millstone. Hard to iterate. Hard for internal teams to maintain. Hard to change without a developer in the room. They eventually moved to LocalGov Drupal in 2022.

The pattern repeats because the failure mode is always the same. Decoupled architectures are brilliant for teams that have the engineering bandwidth to maintain two separate systems, handle cross-cutting concerns like preview and caching in custom code, and keep the whole thing coherent as both sides evolve independently. That's a significant ask for a council digital team with three developers, a backlog full of resident-facing services, and a government accessibility audit on the horizon.

So what's LocalGov Drupal, and why is half of UK local government migrating to it?

The origin story is one of those rare moments where the public sector actually did something smart. Brighton & Hove City Council had been developing a Drupal 8 website. Croydon Council looked at it and thought: we need to do that too, why are we building this separately? They started sharing code. Then a handful of other councils joined. Then the Ministry of Housing, Communities and Local Government funded an alpha. Then it had a name and a community and, eventually, a not-for-profit co-operative to run it.

The core idea is aggressively sensible: every UK council needs broadly the same things on their website. News. Events. Service pages. An alert banner for when it snows or a local election is happening. Step-by-step guides. A directory. So rather than 350-odd councils each commissioning a bespoke solution and paying a vendor to build what everyone else already has, they build it once, together, and share the results under an open source licence.

It's now at over 50 councils and counting. Leeds, Southwark, Haringey, Islington, Greenwich, Kingston, Newcastle, Essex. And now Hackney.

The editorial experience is where the difference is most immediately felt.

In a headless WordPress setup, your content editors are fine. WordPress's block editor is perfectly serviceable. That is, right up until the moment they want to know what something looks like before they publish it. At that point you're either building a full preview environment and wiring it up to your React front-end, or you're telling your editors to use the power of imagination. Neither is great.

LocalGov Drupal keeps the content and the presentation together. Editors work in the same system that serves the pages. The preview is just... the page. Content types like guides, step-by-step pages, service landing pages, and alert banners are purpose-built for how councils actually organise information, not repurposed from a generic blog CMS or an e-commerce platform. The people who designed them were the same people whose colleagues were going to use them.

That matters more than it sounds. A content designer at a council doesn't want to model their service pages around whatever abstraction a headless CMS vendor decided was intuitive. They want something that speaks their language. "Service landing page" is not jargon to them. It's the thing they need.

For developers, the shift is equally significant, for reasons that are slightly harder to articulate to non-technical stakeholders.

A headless WordPress and React setup is a system of two parts that don't inherently know about each other. Every time one part changes - a new content type, a design update, an API schema tweak - the other part needs to be updated in sync. You write glue code. You maintain that glue code. You document it, or more likely you don't, and then six months later someone new joins the team and you watch them try to figure out why the homepage breaks when someone adds a new media type.

With LocalGov Drupal, the Drupal module ecosystem does that integration work for you. Content types come with their display logic. The community has already solved the common problems. When Drupal 9 needed to upgrade to Drupal 10, the LocalGov Drupal community handled that migration collectively, and every council on the platform benefited, rather than each one doing it separately. Same with Drupal 11. Security patches land across the whole ecosystem at once. You're not alone in your stack.

There's also something quietly radical about the community model. If you implement a feature your council needs - elections module, planning applications, a custom directory type - you can contribute it back, and all 50+ councils benefit. If another council already built the thing you need, you can use it for free. It's the kind of unglamorous, collaborative, public-good-oriented software development that doesn't get a TechCrunch writeup but absolutely saves taxpayers money.

Performance and accessibility come baked in. LocalGov Drupal is built against WCAG 2.1 AA standards throughout, with an active Accessibility Governance Group that audits new features before they land in core. For a council website, the digital front door for residents who may have disabilities, limited digital literacy, or both, that's not a nice-to-have. It's a legal requirement, and it's one that bespoke setups routinely fail.

The headless React approach can absolutely achieve WCAG compliance. But it requires deliberate effort on every component, every page, every new feature. With LGD, the baseline is already there. You're not re-solving accessibility for every new piece of functionality.

The broader argument, the one that makes LocalGov Drupal genuinely interesting beyond the technical details, is about what local government digital infrastructure should look like.

The old model was each council commissioning a bespoke website from a vendor every five to seven years, paying for essentially the same functionality each time, and then maintaining a unique snowflake that no other council could help them with. The vendor knew this. The contracts reflected it.

LocalGov Drupal breaks that model. The software is publicly owned. The vendor lock-in is gone. The knowledge is shared. When Hackney moved to this platform, they weren't just launching a new website. They joined a community of digital teams across the country who are working on the same problems, sharing the same code, and making each other's services better.

That's a different kind of infrastructure. Not flashy. Not the sort of thing that gets demoed at a startup pitch night. But the sort of thing that might, quietly, mean that the council website actually works. For the resident trying to find out if their bin will be collected on Christmas Day, for the content editor trying to publish an urgent alert, and for the developer who doesn't want to spend their career debugging a custom serverless preview function at 9pm.

We shipped it today. It took a while. It was worth it.

Hackney Council's new website is built on LocalGov Drupal. If you're interested in how that happened, or you're a council thinking about making the same move, the LocalGov Drupal community is genuinely one of the better corners of the public sector internet.