Azure Migrate

The inventory that turns out to be wrong

Every migration begins with a list of what has to move. That list is almost always incomplete, and the gap is not the result of poor record keeping.

Servers get commissioned during projects and never enter the register. Applications are installed by teams who had a deadline. Someone leaves and the system they maintained continues running with no owner. A virtual machine created for a trial six years ago is still serving something.

The pattern is consistent enough to expect. Any environment of reasonable age contains more than anyone knows about, and the parts nobody knows about are the ones that cause trouble during a migration.

Azure Migrate begins with discovery for this reason.

Discovery

The service examines an existing environment and inventories what it finds: servers, their configuration, what is running on them, databases.

The value is that the result is observed rather than reported. It is what is actually there.

This regularly produces uncomfortable findings. Systems nobody claims. Servers running at almost no utilisation. Software versions that reached end of support some years ago.

All of it is better known before a migration than during one.

Dependencies, which is where migrations break

Discovery answers what exists. The harder question is what depends on what, and dependency mapping addresses it by observing which servers communicate with which.

This matters because of a specific and common failure.

A server is assessed as simple. It runs one application, uses modest resources, and appears to be an easy first candidate. It is migrated over a weekend.

On Monday something unrelated stops working, because it was quietly calling that server for a lookup that nobody documented and the person who built the integration left in 2019.

Observed communication reveals these connections. Systems that must move together become visible as groups, and the migration can be sequenced accordingly.

The alternative to knowing this in advance is discovering it during a cutover, which is the worst available moment.

Assessment

Each discovered workload is assessed for what it would require in Azure, along with an estimate of cost.

This addresses a real question in migration planning. Existing servers were frequently sized generously, for peak load that never arrived or on hardware chosen for a different decade. Sizing based on observed utilisation rather than on existing specification usually produces something smaller and cheaper.

Cost estimates before committing are also valuable in an obvious way. Migrations that turn out to cost more than the environment they replaced are a familiar disappointment, and they are avoidable by estimating first.

The assessment produces information. It does not decide. Whether a workload should move, and whether it should move as it is or be rebuilt, depends on application roadmaps, business timing and other considerations the tooling has no view of.

Migration

Once assessment is done, tooling carries out the moves.

The service covers several workload types, and databases involve different considerations from servers. The official documentation describes which scenarios are supported and which tools apply.

Worth noting is the proportion of effort. The move itself is usually the smaller part. Discovery, assessment, dependency work and sequencing are where the time goes, which is why the service leads with them rather than with migration.

Who uses it

Azure Migrate is used by infrastructure teams, platform teams and migration programmes moving workloads from existing data centres or other environments to Azure. Its users are as often in planning roles as in technical execution ones, because much of what it produces informs decisions rather than performing them.

Points to consider

Azure Migrate is a Microsoft Azure service and the official documentation is the reference for supported scenarios, tooling and prerequisites.

Discovery requires access to the environment being examined, and the documentation sets out what is needed. This is worth establishing early, as it frequently involves other teams.

Dependency mapping observes traffic over a period. A system used monthly will not appear in a week of observation, so the length of the observation period affects how complete the picture is.

Assessment findings are a starting point rather than a decision. Sizing recommendations reflect observed utilisation, which may not include peaks the observation period missed.

Getting started

The official documentation covers setting up discovery, running assessments and the migration tooling for each workload type. Beginning with discovery over a defined portion of an environment, and comparing what is found against the existing inventory, is usually informative in itself.