On-premise to Azure migration

What an Azure migration must accomplish

An on-premise to azure migration moves applications, data, and infrastructure from organization-managed facilities into Microsoft Azure. Successful migrations also transfer operational responsibilities: identity, network routing, monitoring, recovery, cost control, and incident response must work in the destination before production traffic moves.

For decision-makers, the question is not simply whether Azure can host existing systems. It is which workloads should move, what changes they require, and whether the resulting operating model meets business needs. Practitioners need a dependency-aware execution plan with testable readiness gates.

Treat the migration as a portfolio of workload decisions—not a single data-center relocation.

Define the business case and migration boundaries

Start with the event or outcome driving the project. A lease expiration, unsupported operating system, acquisition, recovery requirement, and demand for faster releases each imply different priorities.

Document these constraints before choosing architecture:

• Deadline: Is there a contractual exit date or a flexible modernization window?
• Downtime: How long can each business process stop, including validation?
• Recovery: What recovery time objective (RTO) and recovery point objective (RPO) apply?
• Data location: Which Azure regions meet residency, contractual, and service-availability requirements?
• Economics: Is the goal lower expenditure, reduced capital commitment, improved resilience, or faster delivery?
• Ownership: Who will operate the workload after migration?

Define success in operational terms. Examples include meeting transaction-latency objectives under representative load, demonstrating a restore within the agreed RTO, and assigning every production resource a cost owner.

Compare full operating costs

Build a baseline that includes hardware refresh, hypervisor licensing, storage, backup, connectivity, facilities, and support. Avoid counting sunk expenditure as an immediately recoverable saving.

For Azure, model compute, disks, snapshots, backup, monitoring ingestion, security services, connectivity, and outbound data transfer. Include the overlap period when both environments run.

Use the Azure pricing calculator for estimates, then validate assumptions against measured utilization. Azure Hybrid Benefit may reduce eligible Windows Server or SQL Server licensing costs, but eligibility depends on licensing terms. Reservations and savings plans can reduce suitable consumption costs, yet create commitments that are risky before workloads stabilize.

Step 1: Discover workloads and map dependencies

Inventory applications as business services, not just servers. A three-tier application might depend on a domain controller, shared file server, scheduled batch job, SMTP relay, and license server that never appear in its deployment documentation.

Capture:

• Application owner, business criticality, support status, and maintenance window.
• Operating system, runtime, database engine, and installed agents.
• CPU, memory, disk capacity, IOPS, throughput, and latency across business cycles.
• Network connections, DNS assumptions, certificates, and authentication flows.
• Backup policies, retention obligations, and recovery procedures.
• Hardware dependencies such as USB license keys or specialized appliances.

Use Azure Migrate for discovery, assessment, and migration planning across supported environments. Its capabilities and collection methods vary by source platform and scenario; check the Azure Migrate documentation against your estate before deploying appliances or agents.

Supplement automated discovery with firewall logs, configuration repositories, application tracing, and owner interviews. Automated tools can miss infrequent dependencies such as month-end exports.

Produce decision-ready assessments

For each workload, record a proposed target, migration approach, blockers, estimated costs, downtime needs, and confidence level.

Do not rightsize from averages alone. A server with low average CPU may still require substantial memory or predictable batch throughput. Collect a representative observation window that includes peak periods, then test the proposed Azure configuration.

Also identify systems to retire. Migrating unused servers preserves waste and expands the security boundary.

Step 2: Choose the right destination for each workload

Rehosting everything is fast in some environments, but it often carries legacy administration into Azure. Conversely, rewriting every application can turn a constrained migration into an open-ended development program.

Evaluate managed database targets explicitly. Azure SQL Database is not a drop-in replacement for every SQL Server instance, while Managed Instance offers broader instance-level compatibility without eliminating assessment requirements.

Containers are not a prerequisite for migration. Use them when their deployment and scaling benefits justify the additional change. Avoid coupling an urgent infrastructure move with unnecessary architecture transformation.

Step 3: Establish the Azure landing zone

A landing zone supplies the governance, identity, networking, and operational foundations into which workloads deploy. Microsoft’s Cloud Adoption Framework landing zone guidance provides a useful reference architecture, but its implementation should match organizational scale.

Set subscription and policy boundaries

Choose management groups and subscriptions around ownership, policy, billing, quotas, and operational isolation. Separate production from nonproduction where those boundaries matter; resource groups alone do not provide equivalent separation.

Implement:

• Azure Policy controls for approved regions, required configuration, and permitted services.
• Microsoft Entra ID groups and Azure role-based access control.
• Privileged Identity Management for eligible, time-limited administrative access.
• Tags for owner, application, environment, and cost allocation.
• Central logging, budget alerts, and security monitoring.

Roll out restrictive policies carefully. An untested deny policy can block a deployment or prevent a recovery operation. Budget alerts also do not automatically cap spending.

Build repeatable foundations

Use Bicep or Terraform to deploy networking, identities, monitoring, and workload infrastructure. Store configuration in version control and review changes through a deployment pipeline.

Decide early who owns shared services and who owns application resources. Without that split, teams often discover during an incident that nobody controls both the DNS change and the application deployment.

Step 4: Design connectivity, identity, and security

A hybrid period is normal. Design it deliberately rather than relying on temporary network exceptions that become permanent.

A site-to-site VPN can provide encrypted connectivity with relatively straightforward setup. ExpressRoute provides private connectivity through a provider and may better suit predictable enterprise connectivity requirements, but introduces procurement, routing, and redundancy considerations. Private connectivity should not be assumed to provide end-to-end encryption by default.

Check:

• Nonoverlapping address spaces across Azure and on-premises networks.
• Routing symmetry through firewalls and network virtual appliances.
• DNS resolution for public names, private endpoints, and internal zones.
• Available bandwidth and transfer time for initial replication.
• Latency between components that will temporarily occupy different locations.
• Redundant connectivity aligned with workload availability requirements.

Use Microsoft Entra ID for supported cloud authentication, but do not assume it replaces Active Directory Domain Services for applications requiring LDAP, Kerberos, or domain joins. Those dependencies need a separate design.

Prefer managed identities over stored credentials where supported. Place secrets and certificates in Azure Key Vault, restrict public exposure, and validate administrative access through approved paths.

Step 5: Pilot the migration method and rehearse recovery

Select a pilot that is low risk but architecturally representative. An isolated test VM proves little about a production application with shared authentication and database dependencies.

Match tools to the actual source and destination:

• Azure Migrate: Migration and modernization for supported server migration scenarios.
• Azure Database Migration Service and engine-specific tools for supported database migration paths.
• AzCopy for supported Azure Storage transfers.
• Azure Data Box when offline bulk transfer is more practical than network transfer.
• Azure Site Recovery for supported replication and disaster-recovery scenarios, rather than as a universal migration tool.

Verify current compatibility, regional availability, and online versus offline migration support before promising a downtime window.

Establish acceptance gates

A pilot should demonstrate infrastructure provisioning, replication, application startup, monitoring, security controls, and business-process validation.

Test both backup restoration and the proposed recovery configuration. Availability zones protect against certain infrastructure failures; they do not replace backups or protect against every application error.

Document measured transfer rates and synchronization lag. These observations are more useful for planning than theoretical link speed.

Step 6: Migrate in dependency-aware waves

Group workloads by dependency, business impact, and rollback complexity. Closely coupled application and database tiers often belong in the same wave to avoid latency-sensitive calls across the hybrid link.

For each wave, follow a controlled runbook:

1. Confirm readiness. Resolve critical assessment findings, quotas, access, and licensing.
2. Provision targets. Deploy approved infrastructure and validate routing, DNS, and monitoring.
3. Start replication. Track health, throughput, and synchronization lag.
4. Run isolated testing. Validate functionality without duplicating production side effects.
5. Freeze relevant changes. Control schema, configuration, and deployment changes.
6. Quiesce writes. Stop jobs or traffic as required and complete final synchronization.
7. Cut over. Start services in dependency order and redirect traffic.
8. Validate and observe. Run business checks and monitor agreed indicators.
9. Close the wave. Record acceptance, unresolved issues, and cleanup responsibilities.

Isolated tests must suppress real emails, payments, scheduled jobs, and external integrations unless explicitly approved.

Make rollback technically credible

Define rollback triggers, decision authority, and the latest safe decision point before cutover.

Once users write new data in Azure, switching DNS back to the old environment may lose or split data. A credible rollback requires a plan for those writes: reverse synchronization, reconciliation, restoration, or an explicitly approved loss boundary.

Lowering DNS time-to-live in advance can help, but client caching and persistent connections may still delay traffic movement.

Step 7: Stabilize, optimize, and decommission

During the post-cutover observation period, compare error rates, latency, throughput, resource saturation, and user outcomes against the baseline.

Investigate Azure-specific bottlenecks, including VM and disk throughput limits, storage latency, connection limits, and unexpected cross-region traffic. Monitor cost daily during stabilization because verbose logs, oversized resources, and orphaned disks can accumulate quickly.

Then:

• Rightsize from observed production behavior.
• Schedule nonproduction shutdowns where appropriate.
• Evaluate commitments only after utilization becomes predictable.
• Confirm alert routing, support ownership, and incident runbooks.
• Verify backup retention and restoration evidence.
• Remove temporary access, replication resources, and network exceptions.

Decommission source systems only after formal acceptance and the agreed rollback period. Preserve required records, securely erase retired storage, update asset inventories, and end contracts only when dependencies are resolved.

Common mistakes that undermine Azure migrations

Moving before ownership is clear. Every workload needs a business owner, technical owner, and operational support model.

Assuming the cloud is automatically cheaper. Always-on, oversized VMs can cost more than expected. Evaluate architecture and licensing alongside unit prices.

Copying data-center security patterns unchanged. Broad internal trust and permanent administrator privileges create avoidable exposure. Use scoped permissions and service-appropriate network controls.

Treating replication as backup. Replication can copy corruption or unwanted changes. Maintain separately governed recovery points.

Ignoring unsupported software. A technically bootable VM is not necessarily supported by Microsoft or the application vendor.

Declaring success at first login. Include batch processing, reporting, integrations, restores, and financial workflows in acceptance.

For related platform planning guidance, browse more Migration topics.

Frequently asked questions

How long does an on-premise to Azure migration take?

There is no reliable duration based on server count alone. Dependencies, transfer volume, compliance reviews, connectivity procurement, and allowed downtime usually dominate. Estimate after discovery, then refine the schedule using measured pilot results and wave-level readiness gates.

Can applications move to Azure without downtime?

Some workloads support very short interruptions through continuous replication and controlled traffic switching. Zero downtime requires suitable application architecture, compatible migration tooling, and careful handling of writes and sessions. Treat it as a tested requirement, not an assumed tool capability.

Should we choose Azure VMs or managed services first?

Choose VMs when compatibility and deadline risk outweigh modernization benefits. Prefer managed services when compatibility is proven and reduced infrastructure administration supports the operating model. A staged strategy—rehost first, modernize later—works only if modernization receives explicit ownership and funding.

What is the most important migration readiness check?

Confirm that the complete business service works in Azure and can be recovered within its agreed objectives. That includes identity, DNS, integrations, monitoring, data consistency, and operator access. A healthy VM or successful database connection alone does not demonstrate production readiness.