Migrating government systems to the cloud isn't just a technology decision — it's a strategic shift that affects security, compliance, procurement, and the way your entire team works. After managing cloud migrations across three UK councils, here's my practical guide to getting it right.
Why Azure for Government?
Azure is the dominant cloud platform in UK government for good reason. Microsoft has UK-based data centres (UK South and UK West), holds G-Cloud framework accreditation, and meets the security standards required for OFFICIAL and OFFICIAL-SENSITIVE classified workloads. It also integrates natively with Active Directory, which most councils already use.
Beyond the technical fit, Azure's presence on the G-Cloud framework simplifies procurement. You can purchase Azure services through the Digital Marketplace without running a full tender process, which reduces the time from approval to deployment from months to weeks. Crown Commercial Service framework agreements cover most Azure services, making budget approval significantly easier.
The alternative cloud providers — AWS and GCP — are both capable platforms, but Azure's integration with the Microsoft ecosystem that most councils already run (Office 365, Active Directory, Dynamics 365, SharePoint) makes it the path of least resistance. If your organisation is already paying for Microsoft 365, you likely have Azure AD capabilities you're not using.
Step 1: Cloud Readiness Assessment
Before migrating anything, audit your current estate. Map every application, database, and service. Document dependencies between systems. Identify which workloads are lift-and-shift candidates, which need re-architecting, and which should be replaced entirely with SaaS alternatives.
I use Azure Migrate for discovery and assessment. It scans your on-premise environment, identifies dependencies, and provides sizing recommendations for Azure equivalents. This alone saves weeks of manual work. For applications that Azure Migrate can't assess automatically, I conduct manual reviews — checking framework versions, database dependencies, and integration points.
The assessment should produce four categories of workloads. First, rehost candidates — applications that can move to Azure VMs or App Service with minimal changes. Second, refactor candidates — applications that need some modification, such as replacing file system dependencies with Azure Blob Storage or updating connection strings for Azure SQL. Third, rebuild candidates — applications so tightly coupled to on-premise infrastructure that they need significant rearchitecting. Fourth, replace candidates — applications where a SaaS alternative is cheaper and better than migrating the custom solution.
In my experience across council migrations, roughly 40 percent of workloads fall into the rehost category, 30 percent need refactoring, 20 percent should be replaced with SaaS, and only 10 percent genuinely need rebuilding. Councils that skip the assessment and assume everything needs rebuilding waste enormous amounts of money.
Step 2: Network and Security Foundation
Set up your Azure landing zone before migrating any workloads. This means configuring virtual networks, subnets, network security groups, Azure Firewall or equivalent, and VPN or ExpressRoute connectivity back to your on-premise network. Get this right first — retrofitting networking after migration is painful and risky.
For government workloads, enable Azure Policy to enforce compliance guardrails automatically. The policies I configure for every council migration include blocking resource creation outside UK South and UK West regions, enforcing encryption at rest on all storage accounts and databases, requiring diagnostic logging on all resources, preventing public IP addresses on VMs unless explicitly approved, and enforcing tagging standards so cost allocation is clear from day one.
If you're handling OFFICIAL-SENSITIVE data, you'll also need to configure Azure Private Link for PaaS services, ensuring traffic between your applications and Azure SQL, Storage, and Key Vault never traverses the public internet. This adds complexity but is a non-negotiable requirement for many government classifications.
Network connectivity between on-premise and Azure is typically the first decision point. VPN is cheaper and faster to set up but has bandwidth limitations and higher latency. ExpressRoute provides a dedicated private connection with guaranteed bandwidth but costs significantly more and takes weeks to provision. For most council migrations, I start with VPN and move to ExpressRoute only if performance requirements demand it.
Step 3: Identity and Access
Sync your on-premise Active Directory to Azure AD using Azure AD Connect. Set up conditional access policies, enable multi-factor authentication for all admin accounts (ideally all users), and configure Privileged Identity Management for time-limited admin access.
Conditional access is where most councils underinvest. At minimum, you should configure policies that require MFA for all admin access, block sign-ins from countries where you don't operate, require compliant devices for access to sensitive applications, and enforce session timeouts for high-privilege roles. These policies cost nothing to implement but dramatically reduce your attack surface.
For councils with existing Azure AD tenants (which most have through Microsoft 365), the sync process is straightforward. The tricky part is deciding what to sync — you probably don't want every AD object in Azure AD. Plan your organisational unit filtering carefully and test with a subset before enabling full sync.
Step 4: Phased Migration
Never do a big-bang migration. Start with low-risk, low-dependency workloads — development environments, internal tools, file shares. Build confidence and operational knowledge before touching production systems.
For each workload, follow this pattern: migrate to staging, test thoroughly, run parallel with on-premise, cutover, monitor, decommission old system. Document every step in a runbook that your ops team can follow independently.
The parallel running phase is where most teams cut corners, and it's where most problems surface. Run both systems side by side for at least two weeks for critical applications. Compare outputs, monitor performance, and verify that integrations work correctly. The cost of running parallel is a fraction of the cost of a failed migration that takes down a production system.
I typically plan council migrations in waves of 3 to 5 applications, with two weeks between waves. This gives the ops team time to stabilise each wave before the next one arrives. Trying to migrate everything simultaneously overwhelms the team and multiplies risk.
Step 5: Cost Management
Cloud costs catch people off guard. Set up Azure Cost Management from day one. Configure budgets and alerts. Use reserved instances for predictable workloads (saving 30 to 60 percent versus pay-as-you-go). Right-size VMs — most teams over-provision initially because they're afraid of under-performing. Schedule non-production environments to shut down outside business hours — this alone typically saves 40 to 50 percent on dev and test environments.
The most common cost mistakes I see in council migrations are choosing oversized VM SKUs because the equivalent spec doesn't exist (a 32GB RAM server doesn't need a 32GB Azure VM if it was only using 8GB), leaving orphaned resources running after decommissioning old configurations, not using reserved instances for workloads that run 24/7, and running premium-tier services where standard tier would suffice.
I build cost monitoring into every migration from the start. Weekly cost reviews during the migration phase, monthly reviews after stabilisation, and automated alerts when spending exceeds 80 percent of budget. The goal is to have cloud costs be predictable and controlled, not a monthly surprise.
Common Pitfalls
After three council migrations, these are the mistakes I see most often. Underestimating bandwidth requirements for the migration itself — moving terabytes of data over a VPN connection takes longer than you think. Forgetting to account for data egress costs when Azure services need to communicate with on-premise systems. Not training the ops team before cutover, so the first time they see the Azure portal is when something breaks at 7am on a Monday.
The most expensive mistake is migrating without modernising. If you lift-and-shift a poorly architected system, you just get a poorly architected system in the cloud that costs more to run. The assessment phase should identify opportunities to improve architecture as part of the migration — consolidating databases, replacing scheduled tasks with Azure Functions, moving file shares to Blob Storage with CDN. These improvements add cost to the migration but reduce ongoing running costs significantly.
Timeline and Budget
For a typical council with 10 to 20 applications, the full migration process takes 3 to 6 months. Assessment takes 2 to 4 weeks. Foundation setup takes 2 to 3 weeks. Migration waves run over 2 to 4 months depending on complexity. Optimisation is ongoing but the major work happens in the month after the final wave.
Budget varies enormously depending on scope, but a realistic range for a council migration of this size is £15,000 to £50,000 for the migration itself (external consultancy costs), plus ongoing Azure consumption costs which typically range from £2,000 to £10,000 per month depending on the workloads involved. In most cases, the Azure consumption costs are lower than the on-premise hosting costs they replace, making the migration self-funding within 12 to 18 months.
Need Help?
I offer cloud readiness assessments and full migration services for UK government teams. If you're planning a migration and want to avoid the common pitfalls, get in touch for a free 30-minute discovery call. I'll give you an honest assessment of your readiness and a realistic timeline for your specific situation.