When organisations choose a content management system, they judge it on what it can do: how easy it is to publish, how well it handles their content, what it costs each year. The question of how to leave it usually comes later.
It arrives years in, when the platform no longer fits, costs have crept up, or a better option has emerged. That’s when the real terms of the relationship become clear. You own the content. The vendor controls the format and interface that hold its URLs, metadata and structure.
Councils know this well. In the Government’s 2024 Future Councils pilot report, they described incumbent suppliers building “data fortresses” that make it difficult to export data. The same report estimates that between £300 million and £1 billion of council IT spend each year goes on keeping outdated and legacy systems running.
The true cost of lock-in shows itself on the day you try to leave.
Two councils, two platforms, one obstacle
We've recently helped two councils move away from proprietary platforms. Central Bedfordshire was leaving Jadu. Colchester City Council was leaving Microsoft Dynamics. Both were heading for LocalGov Drupal, built and maintained collaboratively by councils, now powering more than 70 council websites.
Both hit the same obstacle: getting their own content out was harder than it should have been.
Jadu's API didn't provide page URLs, authors, or creation and update dates for most content. Requests for missing data often came back marked as successful, carrying duplicated or empty records. In Dynamics, knowledge articles could be exported through an API. The core web pages and links had to be extracted as a bundle using Microsoft's own command-line tools.
Both problems were solvable, but each added unplanned time, risk and checking. The lesson: ease of exit is a feature of any platform, and the best time to assess it is when you choose one.
Central Bedfordshire: keeping faith with residents
For a council, migration also means protecting everything that points to that content. Residents have bookmarked pages, search engines have indexed them, and other organisations link to them. Broken links cut people off from the services they rely on.
Central Bedfordshire's site had around 48,000 URLs, including documents and images. Because the API left these out, they had to be reconstructed. In testing, Jadu's documented rules for generating web addresses matched only about 60% of real pages. A public service needs close to all of them.
So Phil Norton, one of our lead developers, built a master list. It combined the site’s partly broken sitemap, crawl data the council’s own team had gathered for SEO, and addresses discovered as the migration ran. Every migrated page was matched against that list and given a permanent redirect. Before launch, a report flagged any page missing a redirect, so the team could fix gaps before residents found them. Since launch, the team has kept monitoring for missing pages, because migration continues after go-live.
Making services easier to find
Central Bedfordshire’s site had around 60 directories, holding about 18,500 entries covering everything from schools and car parks to homecare providers. Each had grown its own set of fields and formats. The migration gave each one a structure that suits how residents use it:
- Directories people search now have filters, so someone looking for a park home site can narrow the list by licence type.
- Entries with an address appear on a map, so residents can see where each school, car park or care provider is.
- Reference content, such as the A to Z of recycling, became publications that read as a single guide.
Editors now have a consistent setup across every directory, with filters they can manage themselves.
Throughout, we stayed close to LocalGov Drupal's standard conventions. That keeps the council on the shared platform’s upgrade path, with minimal bespoke code to maintain.
The migration itself was built to be tested and repeated. Each stage could be rerun as content changed during the project, and the whole migration can be run with a single command. Even the largest phases ran in roughly 90 minutes each: around 20,000 pages of guide content, and the full set of directories.
Phil has documented the technical detail in a four-part series on his blog. He’s also preparing a reusable Jadu-to-LocalGov Drupal starter module for release, so the next council has a head start.
Colchester: putting the council in control
At Colchester, the council’s editors wanted to decide what moved and when.
Working alongside The Confident, we built migration tooling that put that control in their hands. Editors upload a list of the content they want to bring across and choose whether to update existing pages. The migration then runs into a staging workspace. There they can check that content, links, redirects and page relationships are correct, and share it with other departments, before anything is published. A log records every run, flagging missing records or mismatches.
About nine days of developer time saved months of manual work, and the council now continues migrating on its own.
"Code Enigma's work saved us hundreds of hours of manual migration, while still allowing for flexibility with each piece of content. This had the added benefit of not disrupting our content designers from their BAU tasks during a very busy time for the council (leading up to an election)."
Mark Conroy, Frontend Lead for LocalGov Drupal and Director at The Confident
Read the Colchester case study
What both projects have in common
The same principles ran through both migrations.
- Understand the data before writing code. In both cases, the real work began by finding out what the source system held and what it would release.
- Fit the method to the organisation. A fully automated migration suited Central Bedfordshire. An editor-led one suited Colchester.
- Protect what people rely on. Redirects, links and relationships between pages were treated as essential.
- Leave the client owning the result. Both councils end up on a platform they co-own, with the knowledge and tools to keep it moving.
Questions to ask before you migrate
Whether you're planning to leave a CMS or choosing a new one, it's worth asking:
- Can we export our URLs and metadata as well as the text?
- Who owns the redirect plan, and how will we know it's complete?
- Who decides what moves, and who checks it before it goes live?
- Will we own the platform we’re moving to?
Planning a move?
If you're considering a move away from a proprietary CMS, we'd be glad to talk it through, whatever stage you're at. Start a conversation.
For technical readers, Phil's full series on migrating from Jadu into LocalGov Drupal covers the code behind the Central Bedfordshire project in detail.