Your government website still works just fine. But, that's possibly what’s making it a little bit dangerous...
It loads. Content gets published. Nobody's complaining. The Silverstripe site your agency launched during the CWP era is still doing its job, or at least, it looks like it is.
But, unless you’ve taken proactive steps, somewhere underneath, things have very likely been quietly drifting. Maybe you have been looking underneath, but the cost:benefit of addressing things has never managed to get budget approval.
The kinds of real-world scenarios we’re familiar with include: aging CMS versions; codebases with dependencies from a platform that stopped being supported five years ago. A lack of test suite. The original requirements (if they were ever written down) have long since parted ways with what the site actually does. And, often, the accessibility standards the site was built to meet have long since moved on without it.
Nothing's on fire. Everything's accumulating. Feature improvements and enhancements have been bolted on but the foundations are now under pressure.
Making things even more challenging, within government agencies, there’s usually been human turnover and we’re increasingly encountering product owners who care deeply for digital services they provide, without necessarily knowing what lies underneath.
We know this world well, because we maintain a number of sites exactly like this. Some we built. Some we’ve inherited. All of them carry the fingerprints of the CWP era - and all of them deserve a better plan than "keep going until something breaks."
Understanding the CWP legacy for government websites
For the best part of a decade, the Common Web Platform gave New Zealand government agencies something genuinely valuable: a standardised, secure foundation for their websites. Silverstripe CMS, bundled hosting, coordinated security patches, shared recipes, compliance built in. Agencies could focus on content and service design without worrying about infrastructure, procurement, or whether their tech stack met government standards.
And it worked. Hundreds of government websites were built on CWP, and, by and large, it raised the bar for public sector digital delivery across the board.
When the CWP agreement expired in September 2021, the immediate conversation felt like it was about hosting - where to move, which Marketplace suppliers to engage, whether to lift-and-shift to AWS or another provider. Those were good enough questions at the time.
But hosting was only ever one layer of what CWP provided. The platform also maintained certain CMS recipes, coordinated updates, and gave agencies a shared technical baseline, particularly for security management & compliance with government standards. When CWP ended, many agencies simply sorted their hosting and then carried on with everything else unchanged.
That was five years ago. The technology and the standards have kept on moving. But we’re seeing that many sites have struggled to.
Why legacy government websites are hard to modernise
Here's the thing about legacy government websites: they rarely fail dramatically. There's no single moment where the site stops working and everyone agrees something needs to be done. Instead, the gap between where the platform is and where it should be opens gradually, a missed Silverstripe update here, a new accessibility standard there, a security patch that can't be applied because the underlying version is too old.
For the product owner or digital lead living with this daily, the pressure is real but maddeningly hard to articulate in a budget conversation. "The site is increasingly out of step with current standards" doesn't compete well against visible, outcome-oriented projects - or new enhancements. It's hard to make the case for investment in something that already appears to work.
This has been compounded by years of constrained government ICT spending. Many agencies have been operating in an environment where maintaining existing platforms - let alone modernising them - has been consistently deprioritised in favour of more visible initiatives. Digital teams have done remarkable work holding things together, often with minimal budget and shrinking internal capability. But the result is a growing number of public-facing platforms that are technically functional and structurally fragile.
The drift is quiet, but it's not free. Every quarter on unsupported software makes the eventual modernisation harder, more expensive, and more disruptive than it would have been if addressed earlier. And the longer it continues, the more the conversation shifts from "planned upgrade" to "forced remediation", which is a much worse position to be making decisions from.
What "works fine" actually looks like under the hood
We've spent over a decade working with government agencies on Silverstripe projects building new platforms, maintaining existing ones, and inheriting systems that other teams built years ago. We're an approved supplier on the Government Marketplace, and this work is a significant part of what one of our dedicated teams does.
The inherited projects are often the most revealing. They arrive with accumulated history, quiet compromises, and a team who knows the site matters but isn't sure where to start when it comes to modernisation.
Here's what we typically find.
The Silverstripe version is way behind. No more security patches. No more bug fixes. Sometimes it's still running CWP-specific recipes that haven't been updated since 2021. We've seen sites on CMS versions which have been unsupported for years.
We’ve also found codebases carrying “dead weight”. CWP recipes bundled modules and configurations that made sense within the platform but serve no purpose outside it. Legacy PHP versions, outdated dependencies, CWP-specific recipe code that's now just unnecessary complexity. Nobody's had the time, budget, or confidence to strip it out, so it sits there, making every change harder and every upgrade more daunting.
There are no tests (or very few). This is staggeringly common. Perhaps the original build didn't include automated testing, and years of incremental changes have compounded the problem. In practise this means every update becomes a nerve-wracking exercise in "change it and see." The absence of test coverage doesn't just slow maintenance it makes the prospect of a major upgrade feel genuinely risky, which is part of why it keeps getting deferred.
Requirements living in people's heads. The documentation if it even existed describes a version of the site that's several years out of date. The people who understood the original decisions have often moved on. What's left is institutional memory, scattered across email threads and the occasional wiki page that nobody's touched since 2019.
Accessibility has drifted. The site may have met WCAG 2.0 or 2.1 when it launched. But the standards have moved on. Gaps have opened quietly - particularly around keyboard navigation, focus management, and mobile usability. For agencies with legal obligations around accessibility, this isn't just a technical shortcoming. It's an exposure.
None of this means your site is about to fall over. But it does means the cost of maintaining it is quietly increasing, the risk profile is gradually worsening, and the distance between where you are and where you need to be is growing wider all the time.
Why the conversation keeps stalling
We understand why modernisation gets deferred. We've sat in enough of these conversations to recognise the pattern.
The site works. The budget cycle rewards visible projects, not invisible maintenance. Modernisation sounds expensive and abstract - it's hard to point to a specific outcome that justifies the spend when the alternative has been working fine so far.
There's also a scoping problem. If you don't have documented requirements, a test suite, or a clear picture of the codebase, it's genuinely difficult to know what modernisation involves. And if you can't scope it, you can't cost it easily. Or your provider defaults to risk-averse pricing with a lot of contingency - and good luck getting that through a budget process that's already oversubscribed.
Then there's the confidence gap. The teams who've been holding these sites together know them intimately, but often that knowledge is practical and operational, rather than strategic. They can tell you what breaks and how to fix it. What they often lack is the technical assessment that translates daily maintenance pain into a business case their leadership will act on.
So it gets deferred. Not because anyone thinks it's the right decision, but because the path forward isn't clear enough to act on. And each deferral makes the next conversation slightly harder.
Why modernising legacy government websites is now easier
Here's the part of the conversation that's shifted meaningfully in the last twelve to eighteen months, and it's the reason we think this is worth writing about now.
We are finding that the cost of modernising legacy platforms has dropped - very significantly.
AI-assisted analysis and development is changing the economics of exactly the kind of work that CWP-era sites need. Reading and interpreting legacy codebases that nobody fully understands. Generating documentation from undocumented systems. Building test suites for code that's never had them. Automating the repetitive, painstaking parts of stripping out legacy frameworks, updating dependencies, and migrating between Silverstripe versions.
The combination of deep domain expertise and AI means this is well beyond speculative. We're doing it right now on real projects. The work that used to require weeks of a senior developer's time - manually tracing through unfamiliar code, writing tests line by line, documenting requirements by reverse-engineering the running system - can now be done in a fraction of the time, with higher coverage and fewer gaps.
On current engagements, we're seeing modernisation costs come in at roughly half what they would have been eighteen months ago. That's not a rounding error. It's the difference between a conversation that stalls on price and one that actually moves forward.
And it's not just cheaper, the output is genuinely better. AI-generated test suites are more comprehensive than what most teams would produce manually under time pressure. The documentation is more thorough. The dependency mapping is more complete. You end up with a codebase that's not just upgraded but genuinely easier to maintain going forward.
For product owners who've been fighting for modernisation budget for years, this is the moment the numbers start working. The essential work that's been sitting in the "too expensive, not urgent enough" category is back on the table and the case for doing it now, rather than deferring it again, has never been stronger.
Upgrade paths for legacy Silverstripe government websites
There's a common assumption that moving off a legacy CWP codebase means a full rebuild. Sometimes it might - and we’re always here for that conversation too. More often, the path forward is an intentional upgrade rather than an outright replacement.
Not all upgrade paths are created equal. Unlike previous upgrades (CMS 3 to 4 was a massive architectural shift), Silverstripe CMS 5 was designed to make the transition from CMS 4 manageable. With core concepts unchanged. That upgrade focuses on dependency updates and removing deprecated code rather than rearchitecting the whole platform. For sites already on CMS 4, the path to 5 is well-documented and, in most cases, achievable without starting from scratch. For most of our sites, upgrading to CMS 6 was more involved than the 4-to-5 transition.
The harder work is usually everything around the CMS. Removing CWP-specific recipe dependencies. Upgrading legacy PHP versions and outdated libraries. Building the test coverage that never existed. Documenting the requirements that were carried in people's heads. Closing the accessibility gaps. Future-proofing the architecture so the next upgrade doesn't require the same conversation all over again.
This is where the combination of deep Silverstripe experience and modern AI-assisted tooling makes a material difference. The technical migration is one thing. Doing it in a way that maintains compliance, keeps the site operational, doesn't blow the budget, and leaves the platform in a genuinely better state for the long term - that's the work that matters.
Start with clarity, not commitment
The most useful first step we've found isn't a migration plan. It's an honest assessment of where things stand.
A focused technical health check can surface the critical issues, separate what's genuinely risky from what's just old, and give you a realistic picture of the effort involved in bringing things to a supported, maintainable state.
We’ve been approaching these with time-bound technical-discovery and reporting engagements. Often these involve a “proof of concept” exploration to help define (and price) higher-risk or more complex aspects of the modernisation journey. The output is a decision-making tool: here's where you are, here's what matters most, here's what your options cost. Sometimes we’re even finding that this is a low-cost moment to implement other nice-to-haves that have sat on product owner backlogs, for example a nice front-end framework modernisation + UI refresh at no extra charge.
This is the work that fundamentally changes the budget conversation. Not "we need to modernise because the technology is getting old" which is true but rarely persuasive, but "here's the specific risk, here's the bounded cost, and here's why doing it now is advantageous."
If you're managing a government website built during the CWP era, the honest answer is: you're not alone, and the first step can be smaller than you expected.
We've been doing this work for a long time. We understand the government context, the procurement realities, and the particular challenges of looking after platforms that were built well for a different era. If you want to talk through where your site stands and what your options look like, we're always happy to have that conversation.
