Solution blueprint
Data center to Azure, in waves
The migration itself is the easy half. The half that decides whether you are better off afterwards is the landing zone, the identity design and who operates it on Monday.
The situation
A company has a data center lease ending and wants to move to Azure rather than renew. The estate is mixed: domain-joined Windows servers, a few Linux application servers, two SQL Server databases, a file share everyone uses and several applications nobody has documented.
The deadline is real, which is useful, and dangerous: it tempts teams to lift and shift everything quickly into a single subscription with no governance, and inherit a worse version of the same problem. This blueprint builds the foundation first and then moves in waves.
Constraints that shape the plan
- A fixed lease end date, so the plan has to fit a calendar.
- Applications with unknown dependencies, discovered rather than documented.
- An existing on-premises Active Directory that applications depend on.
- No agreed address plan, and overlapping ranges in test environments.
- A team that has to run the result, so simplicity beats elegance.
- Recovery expectations that have never been written down or tested.
Landing zone, conceptually
Management
- Management group hierarchy
- Azure Policy for guardrails
- Subscription per environment
- Tagging standard
- Budgets and cost alerts
Set before workloads arrive. Retrofitting governance onto running systems is the expensive path.
Identity
- Entra ID with conditional access
- Privileged Identity Management for admin roles
- Managed identities for workloads
- Domain services or extended Active Directory for domain-joined servers
Decide early how domain-joined applications authenticate in the cloud.
Network
- Hub virtual network with shared services
- Spoke per workload or environment
- VPN or ExpressRoute to the data center during migration
- Private endpoints for platform services
- Centralized egress and inspection if policy requires
The address plan has to cover on premises, cloud and future growth before the first subnet is created.
Platform
- Log Analytics workspace
- Defender for Cloud
- Backup and recovery vaults
- Key Vault for secrets
- Infrastructure as code in version control
Logging and backup are part of the foundation, not a later project.
The approach, phase by phase
Phase 1: Discover and assess
Four to six weeks.
-
1
Inventory with tooling
Agent-based and agentless discovery for servers, with performance data over a full business cycle.
-
2
Map dependencies
Network flow data to find the connections nobody documented, then confirm with application owners.
-
3
Classify each workload
Rehost, replatform, refactor, replace with software as a service, or retire. Retiring things is real progress.
-
4
Capture requirements
Availability, recovery time and point objectives, data residency, compliance and licensing.
-
5
Wave plan
Group workloads so each wave is independently testable and reversible.
Phase 2: Build the foundation
Four to eight weeks.
-
6
Landing zone
Management groups, subscriptions, policy, tagging, budgets, in code.
-
7
Network
Address plan, hub and spokes, connectivity to the data center, name resolution.
-
8
Identity
Conditional access, privileged role management, the approach for domain-joined servers.
-
9
Observability and backup
Log collection, alerting, backup policies and a tested restore.
-
10
Pilot wave
Two or three low-risk workloads end to end, to prove the foundation and the runbook.
Phase 3: Migrate in waves
Ongoing, wave by wave.
-
11
Prepare each wave
Owner sign-off, test plan, cutover window, rollback and a communication plan.
-
12
Replicate and test
Replicate, bring up a test copy, let the application owner verify it, fix what breaks.
-
13
Cut over
In the agreed window, with a checklist and a decision point for rollback.
-
14
Validate
Function, performance, connectivity, backup, monitoring and cost, for each wave.
-
15
Decommission
Only after an agreed quiet period, with backups retained to policy.
Phase 4: Operate and optimize
From the first wave onward.
-
16
Operations handover
Runbooks, alert ownership, escalation paths and on-call arrangements.
-
17
Recovery testing
Test the recovery plan rather than documenting it. Record the results.
-
18
Cost management
Rightsizing, reservations or savings plans where usage is stable, and a monthly review with an owner.
-
19
Security posture
Act on Defender for Cloud findings, close the gaps and set a review cadence.
-
20
Modernization backlog
Replatform the workloads that were rehosted to meet the deadline, now on your own schedule.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Workload inventory with dependencies and performance data
- Migration strategy per workload, including what is retired
- Landing zone design and the code that builds it
- Address plan and network design
- Identity and privileged access design
- Wave plan with cutover and rollback runbooks
- Backup, recovery and monitoring design with a tested restore
- Operations handover pack and runbooks
- Cost baseline and optimization plan
What usually goes wrong, and what we do about it
-
Unknown dependencies
Found with flow data in discovery, not during a cutover weekend.
-
Lift and shift into one subscription
The foundation phase exists precisely to stop this, and it is built in code so it can be changed.
-
Address overlaps
The address plan covers cloud, on premises and growth before anything is deployed.
-
Nobody can operate it
Operations handover is a deliverable with runbooks and named owners, and we train your team as the waves run.
-
Cost surprises
A baseline, budgets and alerts from day one, and a monthly review with an owner rather than a quarterly shock.
-
Recovery assumed rather than tested
We test a restore in the foundation phase and again after the first production wave.
Questions people ask
Can we move everything as-is to meet the deadline?
Often yes for most workloads, and that is a legitimate choice when a lease is ending. Classify the exceptions honestly and keep a modernization backlog instead of pretending the move finished the job.
Do we still need Active Directory?
Usually, for a while. Domain-joined applications need a plan: extend the domain, use a managed directory service, or modernize the application. This gets decided in phase one.
Does this work for AWS or Google Cloud?
The shape is the same: foundation, then waves. The services differ. See the cloud migration planner and our AWS landing zone article.
Can you operate it for us afterwards?
Only under a written agreement that says what we are responsible for and when. We do not advertise around-the-clock operations we have not contracted for.
Related
-
Cloud
Cloud strategy, readiness assessments, migration, landing zones, governance, FinOps and operations on AWS, Azure and Google Cloud.
-
DevOps and platform engineering
CI/CD pipelines, infrastructure as code, Kubernetes, GitOps, observability and internal platforms that help engineering teams ship safely.
-
Cloud migration planner
Answer nine questions about your estate and get an illustrative, phased checklist for moving to AWS, Azure or Google Cloud.
-
Cloud security assessment
Reviewing a multi-account AWS environment: identity, exposure, workloads, logging and what to fix first.
Have a technology challenge? Let’s work out the approach.
Discuss a project
Tell us the current system, the target and the timeline. A technical lead replies to talk about scope.
Start the project briefRequest technical talent
Need consultants inside your team rather than a project owner? Send the requirement.
Request talentBecome a partner
Delivery firm, staffing supplier or consulting partner? Register your company.
Register as a partner