Azure Cloud Migration Assessment: What to Check Before Moving

An Azure migration assessment is the point at which a cloud ambition becomes an accountable engineering decision. Its purpose is not to produce a spreadsheet of servers or a reassuring green score. It must establish which business capabilities are moving, where each workload begins and ends, why Azure is the right destination, which risks remain, how the target will be operated, and what evidence will authorize cutover.

That distinction matters because infrastructure can be copied successfully while the migration itself fails. A forgotten license server can stop production. A database separated from its application can turn a tolerable call into a high-latency bottleneck. A backup can exist without being restorable inside the promised recovery window. A technically accurate cloud estimate can omit support, security logs, network egress, parallel environments, or the people required to operate the result.

Assess complete business services rather than isolated virtual machines. Bring application, infrastructure, data, security, finance, procurement, operations, and business owners into the same evidence trail. Every major conclusion should name its source, owner, confidence, unresolved assumption, and the test that will settle it. Unknowns are acceptable; invisible unknowns are what make a migration dangerous.

The final assessment should be usable. It should contain an agreed portfolio, dependency map, disposition for each workload, target architecture, landing-zone gaps, cost range, risk register, migration waves, acceptance criteria, rollback conditions, and accountable owners. Those artifacts turn discovery into a programme that can be funded, scheduled, challenged, and safely executed.

Build an Inventory That Can Support a Decision

A useful inventory describes a service well enough to make a decision about it. Record servers, virtual machines, containers, databases, web applications, scheduled jobs, queues, file shares, certificates, DNS records, identity providers, external integrations, backup systems, monitoring, build pipelines, and administrative paths. For every component, capture its technical and business owner, purpose, environment, lifecycle status, support contract, runtime and version, deployment method, maintenance window, data classification, and tolerance for interruption.

Do not silently remove dormant or poorly understood systems. Low traffic may mean obsolescence, but it may also identify a quarter-end process, disaster-recovery dependency, compliance archive, or service waiting for an external event. Retirement is a business decision with evidence, an owner, and a retention plan. Until that decision exists, the component remains part of the migration scope or an explicit risk.

Measure behavior across a representative business cycle. Capture CPU and memory distributions, storage capacity, IOPS and latency, network throughput, connection counts, database growth, queue depth, job duration, concurrency, and seasonal peaks. Averages conceal the moments that determine sizing. A system running at 15 percent CPU for most of the month may still require short-lived capacity that protects payroll, settlement, or customer ordering.

Azure Migrate can support discovery, readiness analysis, right-sizing, and estimated Azure resource cost, but its output is evidence rather than a verdict. Review discovery coverage, assessment settings, confidence ratings, pricing assumptions, and utilization history with workload owners. The resulting baseline should also support later decisions about cost optimization after migration, Azure budget drivers, and whether modernization is worth the additional change.

Map Dependencies Before Drawing Migration Waves

A server list shows where software runs; a dependency map shows whether the business service can move. Trace inbound and outbound calls, protocols, ports, DNS resolution, authentication, certificates, data exchanged, volume, latency sensitivity, retry behavior, ownership, and the consequence of failure. Include the unglamorous paths that often surface late: email relays, payment providers, SFTP partners, license services, Active Directory, NTP, print services, monitoring, backup agents, build runners, bastion access, and vendor support channels.

Use several sources because no single discovery method sees the whole system. Network telemetry reveals observed traffic, configuration reveals intended connections, source and pipeline review reveals build-time assumptions, and workshops expose manual work. Each source has blind spots. A two-week trace may miss month-end settlement; an architecture diagram may describe a connection that disappeared years ago. Mark every edge as observed, declared, inferred, or unverified.

Convert the dependency graph into migration units. Components that require low latency, shared transactional consistency, coordinated release, or common recovery usually belong in the same wave. For every temporary hybrid path, define routing, name resolution, identity, encryption, capacity, monitoring, cost, duration, and owner. “Hybrid for a while” is not a design unless the exit condition is explicit.

Sequence waves around business risk and learning value, not convenience alone. A first wave should be representative enough to test the landing zone and operating model, yet bounded enough to recover safely. Document entry criteria, rehearsal results, change freeze, cutover steps, validation, communications, rollback trigger, rollback deadline, and who has authority to call each decision.

Choose the Right Destination for Applications and Data

Migration strategy is a portfolio decision, not a slogan. Choose whether to rehost, replatform, refactor, replace, retain, or retire each workload according to business horizon, technical condition, risk, operating burden, and available change capacity. Rehosting can reduce simultaneous change and shorten a data-centre exit. Replatforming may remove undifferentiated operations. Refactoring can unlock scale or delivery speed, but it also enlarges the regression surface and complicates rollback. A workload nearing retirement may deserve containment rather than reinvention.

Test application fit against the proposed Azure service. Check operating-system and runtime support, vendor certification, drivers, appliances, privileged operations, local disk state, filesystem semantics, session handling, hard-coded names and addresses, clock assumptions, batch windows, autoscaling behavior, observability, and deployment rollback. A service being technically available in Azure does not prove that its quotas, maintenance model, regional features, or failure behavior fit the workload.

Assess data as a governed asset. For every dataset, document the owner, system of record, classification, residency and sovereignty rules, retention and deletion obligations, encryption and key ownership, schema, size, growth, change rate, consistency model, transfer path, downtime tolerance, and consumers. Select offline transfer, continuous replication, or another method from these constraints. Estimate the initial copy and the change backlog under realistic encrypted throughput.

Define validation before moving data. Technical checks include counts, checksums, constraints, replication lag, and error logs; business reconciliation includes balances, document totals, inventory positions, or another domain truth. Decide how writes will be frozen or synchronized, how the final delta will be applied, and who accepts the result. For complex estates, treat database migration to Azure as its own engineered workstream rather than a line in the server plan.

Prove Security, Compliance, and Landing-Zone Readiness

Security assessment begins with obligations. Map laws, regulatory controls, customer contracts, internal policies, audit evidence, data-location restrictions, and incident-reporting commitments to qualified owners. Then trace how the target architecture will satisfy them. “Azure is compliant” is not a control statement: the cloud provider secures its part of the platform, while the organization remains responsible for configuration, identity, data, applications, monitoring, and operation within the shared-responsibility model.

Inventory human users, privileged roles, service accounts, workload identities, secrets, certificates, keys, and trust relationships. Design Microsoft Entra ID integration, least-privilege role-based access, privileged access workflows, managed identities, secret rotation, Key Vault, emergency access, and separation of duties. Test authorization from the resource and data plane, not merely successful sign-in. Migration is an opportunity to remove permanent administrator rights, undocumented shared credentials, and secrets embedded in code or pipelines.

The Azure landing zone must exist as an operable product before production workloads depend on it. Define management groups, subscriptions, resource organization, naming, tagging, approved regions, policy, budgets, quotas, network topology, DNS, private access, egress control, centralized logs, security monitoring, backup, patching, deployment pipelines, and incident access. Express repeatable controls as code, review exceptions, and assign platform ownership.

Test guardrails with a representative deployment before cutover. A policy that correctly denies an unapproved resource can still derail a migration if the application team discovers it during the change window. Confirm diagnostic settings, log retention, alert routing, Defender plans, vulnerability handling, encryption, key recovery, evidence export, and break-glass procedures. Record which controls are inherited from the platform and which remain the workload team’s responsibility.

Turn Networking and Recovery into Measurable Commitments

Cloud networking should be assessed as a service dependency, not a diagram. Plan non-overlapping address space, routing, DNS forwarding, private endpoints, ingress, egress inspection, partner connectivity, administration, and segmentation. Decide where traffic is inspected and where names resolve during every migration phase. Give each firewall rule a purpose, owner, source, destination, review date, and expiry when temporary.

Measure latency, packet loss, and effective encrypted throughput over the proposed VPN or ExpressRoute paths with representative payloads and concurrency. Headline circuit capacity does not predict transfer time after protocol overhead, encryption, congestion, small files, or application serialization. Model normal traffic, bulk migration, backups, replication, monitoring, and recovery competing for the same path. Confirm quotas and lead times early enough to change the plan.

Business owners must define availability, recovery time objective, and recovery point objective for each critical business flow. Engineers then translate those commitments into zones or regions, redundancy, replication, backup frequency, retention, immutable copies, restore design, failover orchestration, staffing, and cost. A universal “high availability” label conceals trade-offs; different services may need different recovery tiers.

Prove recovery through exercises. Restore data into an isolated environment, start dependencies in the correct order, validate identity and networking, measure detection and decision time, verify application and business integrity, and record human steps. Define the cutover rollback trigger, the last safe point to invoke it, and how data written on either side will be reconciled. The broader design belongs in an explicit Azure availability and disaster-recovery plan, not in an unchecked backup box.

Model the Cost of Operating, Not Merely Hosting

A credible financial model starts with the measured current estate and compares like with like. Model compute, operating-system licenses, managed databases, storage capacity and transactions, backup, replication, network egress, private connectivity, firewalls, gateways, public addresses, DNS, monitoring ingestion and retention, security services, support plans, and every non-production environment. Separate fixed, usage-based, and growth-sensitive costs so that decision-makers can see what changes the forecast.

Validate license mobility, product terms, vendor support, Windows Server and SQL Server benefits, and commitment eligibility with procurement, legal, and technical owners. Do not assume every installed product can move or that every theoretical Azure Hybrid Benefit is available. Likewise, do not buy reservations before the workload stabilizes merely to make the business case attractive. Commitment discounts reward predictable demand; they do not repair poor sizing or uncertain architecture.

Add the cost of change: assessment tooling, migration services, data transfer, parallel environments, remediation, testing, security review, training, platform engineering, on-call coverage, vendor help, and post-cutover stabilization. Include the remaining on-premises cost during the overlap and the decommissioning work required to realize savings. A calculator estimate describes resources; an operating budget describes the service and the people around it.

Present a range for steady demand, peak demand, expected growth, and significant failure or recovery scenarios. Assign a cost owner, budget, tags, anomaly alerts, and review cadence before migration. State which assumptions are measured and which remain provisional. This creates the baseline from which post-migration optimization can improve efficiency without quietly removing resilience, performance headroom, or operational evidence.

Azure Migration Readiness Checklist

• Portfolio evidence: every component belongs to a business service and has technical and business owners, lifecycle status, support position, representative utilization, data classification, and an explicit migrate, modernize, retain, replace, or retire decision.
• Dependencies and waves: calls, data flows, identities, certificates, rare jobs, vendors, administrative paths, and temporary hybrid connections are documented, assigned confidence levels, grouped into migration units, and tested against the proposed sequence.
• Target fit: the selected Azure service and migration strategy satisfy compatibility, performance, quota, security, compliance, data, deployment, observability, support, and day-two operating requirements with recorded evidence.
• Operational proof: the landing zone, connectivity, identity, monitoring, backup, restore, failover, deployment, cutover, rollback, reconciliation, support model, and business acceptance have been rehearsed with named decision-makers.
• Commercial readiness: licensing, migration effort, parallel operation, steady and peak cloud consumption, growth, security, support, people, decommissioning, and recovery scenarios are funded, assigned to cost owners, and monitored after cutover.