Azure migration: what to settle before moving servers

Moving servers to Azure is often pitched as a weekend job: replicate the virtual machines, switch them on in the cloud, retire the old hardware. For a small or mid-sized organization, the replication is rarely what goes wrong. What goes wrong is everything nobody wrote down: the forgotten server a finance application still talks to, the admin account that turns out to own the whole subscription, the monthly bill that arrives at twice the estimate, and the cutover weekend with no agreed point at which to turn back.

This guide is for owners, operations leads and IT managers at Canadian organizations who are weighing a move of on-premises servers to Azure. It sets out the decisions to settle before the first workload moves, in an order that keeps the old environment as a safe fallback until the new one has proved itself.

Start with an inventory you can trust

Every migration plan rests on a list of what exists. In most environments that list is out of date. Microsoft's own migration service, Azure Migrate, starts with discovery and assessment for exactly this reason: it reports whether each server, database and web application is ready for Azure, suggests a size for each one, estimates what it would cost to run, and analyzes how servers depend on each other.[1]

The output is only as useful as the questions you ask of it. For each workload, record:

• The business owner, not just the server name. Somebody has to decide when the application can be down and accept that it works afterwards.
• What it is for and how critical it is. Payroll in the last week of the month is not the same workload as a test server.
• Its current performance. A baseline of normal response times and resource use is what you will compare the Azure version against.
• Whether it should move at all. Some systems are better retired, replaced with a software service, or left where they are.

Map dependencies before you group servers

Applications rarely live on one server. A line-of-business system may need a database server, a file share, a licence server and an old print or scanning service that nobody remembers until it stops answering. Move one without the others and the application fails in ways that look like an Azure problem but are not.

Azure Migrate's dependency analysis exists to catch this. The agentless option captures network connection data from the servers you enable it on, so you can group interdependent servers into applications and identify the servers that must move together.[2] Microsoft describes the purpose plainly: making sure nothing is left behind, so there are no surprise outages after migration.[2]

Give dependency analysis time to see a full business cycle. A server that is only contacted at month-end, quarter-end or during payroll will not appear in a few days of data. Run collection across the busiest period you have, then have each application owner review the map before it becomes the plan.

Be clear about what you still own

Moving a virtual machine to Azure changes who looks after the building, the hardware and the hypervisor. It does not change who looks after the server. Microsoft's shared responsibility model states that for every cloud deployment type, you own your data and identities, and you remain responsible for accounts, access management and the devices that connect to the service.[3] For virtual machines in particular, the operating system, the applications and the network controls stay with you.[3]

In practice, a lift-and-shift migration keeps every patching, backup, monitoring and hardening task you have today and adds new ones. Decide before the move who will do that work in Azure, with what tools, and how it will be checked. If the answer is "the same person, in their spare time", the migration has not reduced risk.

The Canadian Centre for Cyber Security makes the same point for cloud adoption generally: organizations should not assume they can shift most privacy, security and compliance responsibilities to the provider, and existing policies may need updating for areas such as roles and responsibilities, data residency, identity integration, encryption, backups and decommissioning.[4]

Build the foundation before the first workload

The most common shortcut is to create one subscription, give one person owner rights and start moving servers into it. It works for the pilot and becomes very hard to unpick later. Microsoft's guidance is to establish a foundation first, called a landing zone, which defines how resources are organized, how governance is enforced and which shared capabilities, such as connectivity, security monitoring and identity services, are provided centrally.[5]

A small organization does not need the full enterprise reference design, but it does need answers to the same questions:

• Identity: who has administrative rights in Azure, whether those accounts are separate from day-to-day accounts, and whether multifactor authentication and an emergency access account are in place.
• Structure: how production, test and retired systems are separated, so a mistake in one cannot reach the others.
• Network: how the office and the cloud connect, which traffic is allowed between them, and which systems are reachable from the internet. The Cyber Centre's guidance on cloud network security zones applies the same zoning principles as an on-premises network, adapted to software-defined cloud networking.[6]
• Cost guardrails: budgets and alerts set before the bill arrives, plus tagging so each cost can be traced to an owner.

Settle data residency in writing

Many Canadian organizations want their data to stay in Canada, either because a client contract requires it or because their obligations under Canadian privacy legislation make it the simpler position to defend. Choosing a Canadian region for the virtual machines is a start, but it is not the whole answer. Backups, logs, monitoring data and any added services each have their own location settings.

The Cyber Centre recommends reviewing data residency policies and service choices against your own regulatory environment, noting that some services and data centres may not be in Canada, and documenting approved geographic locations and encryption requirements in the service agreement.[7] Write down where each category of data will be stored and check the setting for each service, rather than assuming the region choice carries through.

Plan the waves, the cutover and the way back

Microsoft's migration planning guidance recommends moving critical systems only after initial success, adding one or two representative complex workloads to early waves to surface problems, and scheduling around critical business periods such as financial close.[8] It also distinguishes two methods: migration with planned downtime, which is simpler, and near-zero downtime migration with continuous replication, which suits critical workloads but needs more setup and testing.[8]

Above all, it calls for a rollback plan agreed before the move: a shared definition of what counts as a failed deployment, specific conditions that trigger a rollback, workload-specific rollback steps, and a test of those steps in a non-production environment.[8] For a server migration, the most reliable rollback is simple: keep the original server intact and powered off, not deleted, until the Azure version has run through at least one full business cycle.

Before each cutover, confirm:

1. The application owner has signed off the test results against the performance baseline.
2. DNS, firewall rules and any hard-coded addresses have been listed, with the change and the reversal for each.
3. Backups of the Azure copy are running and one restore has been tested.
4. Monitoring and alerting are in place, and someone is watching for the agreed window afterwards.
5. The named person with authority to call a rollback is reachable throughout.

Decommission deliberately

The migration is not finished when the Azure server is running. It is finished when the old server has been retired on purpose: data securely removed, licences and support contracts ended, firewall rules and DNS records cleaned up, and the inventory updated. Old servers left switched on "just in case" become unpatched systems that still hold real data.

Where this fits

An Azure move touches several kinds of work at once. Our cloud services work covers readiness assessment, landing zone design, migration planning and cutover. Our network architecture and segmentation service covers the connectivity and zoning between your office and Azure, and the managed IT services page explains how ongoing patching, backup checks and monitoring are handled after go-live.

If you are considering a move to Azure and want the plan checked before the first server is replicated, contact HAI Consulting for a free initial consultation. We will look at what you run today, what depends on what, and tell you plainly what needs to be settled first.