Digital transformation in UK local government involves user needs, legacy systems, shared services, and governance. This guide explores practical considerations for planning and delivering digital services.
Start With the Problem, Not the Technology
Start by understanding what residents and staff need before choosing a platform. Define the problem and how you will measure improvement, then compare technical approaches against those requirements.
Talk to your users first. Sit with the staff who use the current system. Watch them work. Ask what's slow, what's confusing, what they've built workarounds for. The insights from two days of user observation are worth more than six months of requirements documents written in a meeting room.
The technology choice should follow from the problem definition, not precede it. Sometimes the right answer is a custom .NET application. Sometimes it's a configured SaaS product. Sometimes it's a spreadsheet with some validation rules. The cheapest and fastest solution that solves the problem is usually the best one — not the most technically impressive.
GDS Standards Matter
The Government Digital Service design principles exist for a reason. "Start with user needs", "do the hard work to make it simple", and "iterate, then iterate again" aren't just slogans — they're the difference between services people use and services people avoid. Apply them even if you're not building a central government service.
The GDS Service Manual provides guidance for discovery, alpha, beta and live services. Check which service standards and assurance processes apply to your organisation and funding arrangements.
The most valuable GDS practice for local government is the service assessment. Having an independent panel review your approach before you commit significant budget catches problems early. Use the assessment to challenge assumptions and identify user needs before committing to a larger build. If your council doesn't run formal assessments, create a lightweight version — even having a colleague from another department challenge your assumptions helps.
Plan accessibility from the start. Current GOV.UK guidance for public sector bodies specifies WCAG 2.2 AA and an accessibility statement, subject to the applicable exemptions and disproportionate-burden provisions. Test with disabled users and assistive technologies as well as automated tools.
Legacy Systems Are the Real Challenge
Every council has systems from the early 2000s (or earlier) that are critical to daily operations but painful to maintain. Planning systems, revenues and benefits, housing management, environmental health — these are often the systems most in need of modernisation and the hardest to change. They're typically built on old technology stacks, have no automated tests, and the original developers left years ago.
Consider incremental replacement where the old and new systems can safely coexist. Define service boundaries, data ownership and rollback conditions before routing users to a replacement. The right approach depends on the system and its constraints.
This is the strangler fig pattern applied to local government IT. Start by building an API layer that exposes data from the legacy system. Build new citizen-facing interfaces that consume the API. Gradually move business logic from the legacy system to modern services behind the API. Over time, the legacy system shrinks until it can be switched off entirely.
The critical insight is that you don't need to modernise everything at once. Modernise the parts that are causing the most pain, delivering the least value, or creating the biggest security risk. A partial modernisation that improves the daily experience for staff and residents is infinitely better than a complete modernisation that never ships.
Shared Services Work (With the Right Approach)
Sharing development teams across multiple councils makes financial sense. A senior developer costs the same whether they're serving one council or three. Shared platforms reduce duplication — three councils don't need three separate online forms systems. And shared teams maintain knowledge continuity even when staff at individual councils move on.
But shared services only work if you standardise where possible and customise where necessary. Trying to build completely bespoke systems for each council defeats the purpose of sharing. Equally, forcing identical solutions on councils with genuinely different needs creates frustration and workarounds that undermine the system.
The approach that works best in my experience is a shared platform with configurable elements. The core functionality, infrastructure, and deployment pipeline are shared. Council-specific elements — branding, terminology, workflow rules, form fields — are configurable without code changes. This gives each council ownership of their service while keeping the development and maintenance burden centralised.
Governance is the hardest part of shared services. When three councils share a development team, prioritisation becomes politically sensitive. A clear governance framework with transparent prioritisation criteria prevents the loudest council from dominating the roadmap. Regular steering group meetings with representation from all partner councils keep things fair and visible.
Procurement Doesn't Have to Be Painful
Agree the procurement route with your procurement team before commissioning work. A framework listing does not remove the need to follow its buying process, check service scope and evaluate suppliers. Do not assume that a purchase value alone permits a direct award; check current procurement requirements and your council's contract procedure rules.
When procurement is necessary, the key to keeping it manageable is a clear statement of requirements. Vague requirements lead to vague proposals, which lead to lengthy evaluation processes and disappointing outcomes. Be specific about what you need, what success looks like, and what your constraints are. The better your brief, the better the responses you'll receive.
For software development, I recommend against traditional waterfall procurement where you specify every requirement upfront and select a supplier to deliver the whole thing. Instead, procure iteratively — buy a discovery phase first, then use the findings to procure the build phase. This reduces risk because you're making smaller commitments based on better information.
Security and Compliance Aren't Optional
Define security and data-protection requirements for the particular service. Agree applicable certifications, network requirements and assurance with the organisation's security and procurement teams. Include design reviews, dependency checks, access controls and a proportionate testing and monitoring plan; a provider's certification does not establish compliance for your application.
Bolt-on security after the fact is expensive and incomplete. If you've built an application without considering security and then run a penetration test, you're likely to find fundamental issues that require significant rework. It's far cheaper to get security right from the start than to retrofit it later.
Data Protection Impact Assessments (DPIAs) should be standard practice for any system handling personal data. They're legally required for processing that's likely to result in high risk, and they're good practice regardless. A DPIA forces you to think carefully about what data you're collecting, why you need it, how you'll protect it, and how long you'll keep it. This exercise often reveals that you're collecting data you don't need, which simplifies the system and reduces your regulatory burden.
What's Next
Cloud-first policies are driving Azure and AWS adoption across local government. Low-code platforms like Power Platform are handling simpler workflows and forms. AI is starting to appear in customer service through chatbots, automated triage of incoming requests, and document classification. But the fundamentals haven't changed: understand your users, build iteratively, test with real people, and ship working software regularly.
The councils that succeed with digital transformation aren't the ones with the biggest budgets or the newest technology. They're the ones that focus relentlessly on user needs, build small and iterate, and treat technology as a tool for solving problems rather than an end in itself.
How I Can Help
I've spent my career building digital services for UK local government. If your council is planning a digital transformation initiative, modernising legacy systems, or looking for senior .NET and Azure expertise, I'd welcome a conversation. Get in touch for a free 30-minute discovery call where I can share relevant experience and give you an honest assessment of your options. You can also read about my Azure migration and legacy modernisation services for more detail on how I work.