Digital transformation is the most overused term in government IT – and the least specific.
Every agency has a digital transformation strategy. Fewer have a clear answer to what it actually requires, beyond replacing old software with newer software and calling it progress.
For government agencies specifically, transformation doesn’t fail because the ambition is wrong. It fails because the private-sector playbook – move fast, iterate, replace legacy systems wholesale – doesn’t map cleanly onto an environment built around procurement cycles, compliance obligations, and systems that can’t simply be switched off while a better version is built.
What actually has to happen first
Before any transformation initiative touches a citizen-facing service or a new platform, there’s foundational work that rarely makes the strategy deck: understanding what data actually exists, where it lives, who owns it, and whether it’s trustworthy enough to build anything new on top of.
Most agencies inherit decades of systems that were never designed to talk to each other. Data sits in silos because the systems that created it were procured years apart, by different teams, for different purposes. “Transformation” that skips straight to new interfaces or AI-driven services without addressing this foundation tends to produce exactly what it was meant to fix: another disconnected system, this time with a better front end.
Compliance is a design constraint, not a final checklist
In the private sector, compliance is often something you check before launch. In government, it has to be part of how the system is designed from the outset – the ASD Essential Eight isn’t a box to tick after the fact, and data sovereignty requirements shape architecture decisions long before anyone talks about user experience.
This is where a lot of transformation initiatives quietly stall: not because the technology doesn’t work, but because it was built assuming compliance could be retrofitted. It can’t, not without significant rework, delay, and cost blowouts that make the next transformation initiative harder to get funded.
Budget constraints change what “transformation” can mean
Private-sector transformation often assumes a level of capital investment and risk tolerance that doesn’t exist in the public sector. Government budgets are scrutinised, cyclical, and rarely allow for a wholesale rip-and-replace approach – which means transformation has to be sequenced: what moves first, what runs in parallel with legacy systems during a transition period, and where the actual risk sits if something goes wrong mid-migration.
This is less exciting than a full modernisation story, but it’s the version that actually gets delivered. The agencies that make real progress aren’t the ones with the boldest transformation vision – they’re the ones with the most realistic sequencing.
What a realistic transformation roadmap actually looks like
In practice, the agencies we work with tend to move through the same rough sequence, even when their starting points differ significantly:
- An honest audit of what data and systems currently exist, and what state they’re actually in – not what the documentation says, but what’s true in production.
- A foundational data strategy that makes information usable and trustworthy across systems, before any new service is built on top of it.
- A sequenced modernisation plan that keeps critical services running throughout, rather than a single high-risk cutover.
- Compliance and security built into the architecture from the start, not layered on afterwards.
None of this is as compelling as “we’re transforming service delivery for the digital age.” But it’s the version that survives contact with a live production environment, a procurement cycle, and an audit.
The agencies that get this right treat transformation as infrastructure work with a user-facing outcome, not a user-facing initiative with infrastructure as an afterthought.
If your agency’s transformation strategy is further ahead on the vision than on the data foundation underneath it, that gap is worth addressing before the next phase of the roadmap, not after.
