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. This guide covers practical considerations for planning a council cloud migration.
Why Azure for Government?
Assess Azure against your workload, residency, identity and operational requirements. Microsoft publishes UK G-Cloud scope and compliance information. In-scope provider services can support government workloads, but customers remain responsible for the components and configuration they operate.
Confirm the current framework, lot, service listing and buying process with your procurement team. G-Cloud inclusion is not a blanket security approval or a guarantee of a particular procurement timescale.
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. Review the discovery output and validate important dependencies with the team. 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.
The appropriate mix of rehosting, refactoring, SaaS replacement, and rebuilding depends on the systems being assessed. Review each workload before choosing an approach, rather than assuming everything needs rebuilding.
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.
Define the required regions, encryption, logging, access and tagging controls with the organisation. Use applicable Azure Policy controls and review exceptions; policy configuration does not by itself establish compliance.
Choose private endpoints, network restrictions and other controls from the workload's risk assessment and the organisation's security requirements. Classification alone does not define a complete architecture; check the selected services, configuration and assurance evidence.
Compare VPN and ExpressRoute against the workload’s bandwidth, resilience, latency and cost requirements. Confirm provider lead times and test the connection before planning a cutover.
Step 3: Identity and Access
Plan hybrid identity using Microsoft Entra ID and an appropriate synchronisation approach for your estate. Test a limited scope first, define emergency access, and agree multifactor authentication and privileged-access controls before rollout.
Conditional Access is a licensed feature. Microsoft's licensing guidance specifies Entra ID P1 for Conditional Access and P2 for risk-based policies. Check existing entitlements and dependencies such as device management. Pilot policies and protect emergency access before enforcing them.
Review which on-premise identities and attributes need synchronising to Microsoft Entra ID. Avoid assuming that every directory object belongs in the cloud; document filtering and test representative users and applications.
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.
Group applications into migration waves based on dependencies and risk. Allow time between waves to validate behaviour and resolve operational issues; the size and spacing of waves depend on the estate.
Step 5: Cost Management
Build a workload-specific cost model using current service prices and measured utilisation. Consider reservations only where the commitment suits the workload, and schedule non-production shutdowns only where operational needs allow. Validate savings instead of assuming a fixed percentage.
Review oversized resources, orphaned services, licensing, transfer charges and service tiers. Compare measured usage with the required capacity before changing the configuration.
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
Migration risks include 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
Illustrative planning example, not a quote or a measured project outcome: an estate of 10 to 20 applications might be modelled over 3 to 6 months, including 2 to 4 weeks for assessment, 2 to 3 weeks for foundations, and 2 to 4 months for migration waves. Dependencies, assurance and recovery requirements can change the schedule.
For the same illustrative example, a preliminary model might use £15,000 to £50,000 in migration consultancy and £2,000 to £10,000 per month in Azure consumption. These figures are assumptions to replace with a scoped quote and current workload costs. Compare the full costs of both environments; a migration is not guaranteed to pay for itself.
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.