Compatibility, dependencies and the things that do not move

Why this matters

The previous lesson sized a workload. This one asks a prior question: can it go at all, and what comes with it?

Migrations fail at cutover far more often for dependency reasons than for capacity reasons. A system moves, works in testing, and then something breaks that nobody knew was connected — a scheduled job on another server, a hard-coded address, a licence check that cannot reach its server, a report nobody mentioned because it has run unattended for six years.

The discipline here is discovery, and the most valuable output is an honest list of what is genuinely blocked. Deciding early that a workload stays where it is saves more than any amount of clever engineering later.

The lesson

Mapping dependencies before migration, and the ones nobody documented

Documentation describes the system as designed. Migration fails on the system as it grew. So dependency mapping must be observed, not asked for.

Methods, weakest to strongest:

• Ask the owners. Necessary, and reliably incomplete. People describe what they use, not what uses them.
• Read configuration. Connection strings, host files, environment variables, scheduled tasks, firewall rules.
• Observe the network. Flow logs, connection tables, or a period of capture. This finds the inbound connections nobody knew about, which are the dangerous ones.
• Dependency-mapping tooling. Agents that build a communication graph over a period. The best option when available.

Observe for long enough to catch infrequent traffic. A nightly job appears within a day; a monthly reconciliation needs a month; an annual process will not appear at all and must be asked about explicitly.

Categories that are reliably missed:

• Inbound connections from systems you do not own — a partner's feed, a reporting tool, a monitoring probe.
• Scheduled jobs on other machines that connect in to pull data.
• Hard-coded IP addresses in scripts and configuration, which break as soon as addressing changes.
• Shared file paths and mapped drives.
• Certificates and the hostnames they are issued for.
• Outbound calls to services with IP allow-lists, which will reject the new source address — an easy fix that must be arranged in advance with a third party.
• DNS entries pointing at the old host that nothing appears to use.

Produce a diagram plus a list of every connection with direction, protocol, port, frequency and owner. The direction matters most: outbound dependencies you control, inbound dependencies are someone else's change.

Operating system and application support matrices, and the unsupported version

Compatibility has three layers and all three must hold.

The operating system. Providers publish supported images and supported guest operating systems. An old OS may boot and still be unsupported, which means no drivers, no agent, and no help when something fails. Very old systems may not boot at all: missing drivers for the platform's virtual devices, or a requirement for legacy BIOS where the platform expects UEFI.

The application vendor. Independent of the provider, and it is the one people forget. Many vendors state which virtualization platforms and which cloud providers they support. Running unsupported may void support and, for regulated systems, void a certification. Check the vendor's matrix and check whether your version is still supported at all.

The architecture. 32-bit software, dependencies on specific CPU instructions, or software built for a different processor architecture — an increasingly live question as ARM-based instances become common and cheap. Software must be available for the architecture chosen.

The recurring scenario is the unsupported version: an application several major versions behind, still running, whose vendor will not support it in a cloud. The genuine options are to upgrade first, move it as-is and accept the risk, replace it, or leave it. All four are legitimate; pretending the problem does not exist is not.

Upgrading during a migration is tempting and usually wrong: it combines two changes so that any failure has two possible causes. Move, stabilise, then upgrade — or upgrade, stabilise, then move.

Hardware-bound software: dongles, licence servers and fixed MAC addresses

Some software is tied to physical hardware in ways a cloud cannot reproduce.

• USB dongles. Physical keys that must be present. No mainstream cloud lets you plug one in. Workarounds — USB-over-IP from a machine that still has the dongle — are fragile and often breach the licence. Frequently a genuine blocker.
• MAC-address licensing. Some licences are bound to a network adapter's address. Cloud NICs get new addresses, so the licence invalidates on migration and sometimes on every restart. Re-issue is a vendor conversation, and the answer is sometimes no.
• Licence servers that must be reachable and may themselves be hardware- bound, creating a chain where the dependent application cannot move until the licence server does.
• Specialist hardware — serial devices, acquisition cards, fax boards, telephony interfaces, HSMs. Cloud HSM services exist and are usually the answer for that last case; the others generally are not addressable.
• Trusted platform modules and hardware-bound encryption, where keys sealed to physical hardware cannot be moved. Migrating means re-keying, which means decrypting first, which requires planning.

Find these early. They are not engineering problems to be solved during cutover; they are constraints that change the plan.

Latency-bound pairs that must move together or not at all

The previous lesson introduced the chatty application. In dependency mapping it becomes a concrete rule: certain pairs of systems must be treated as one unit.

The pairs to look for:

• Application and its database, especially with per-row rather than set-based access.
• Application and a shared file store used for real-time reads.
• Middleware and the services it brokers.
• Any pair exchanging many small synchronous messages per user action.

Where a pair cannot be split, the options are: move both together; introduce caching or batching to cut round trips first; accept degraded performance with the business's agreement; or leave both where they are.

This is what produces migration waves — grouping systems so that each wave is self-contained and nothing chatty is left straddling the boundary. Planning waves badly is the reason the middle of a migration is often slower than either end state, and a scenario describing exactly that is testing this idea.

Deciding honestly that a workload stays where it is, and recording why

Not everything should move, and saying so early is a professional outcome rather than a failure.

Legitimate reasons to leave a workload:

• A hard blocker: a dongle, hardware-bound licensing, specialist hardware, an unsupported system the vendor will not certify.
• Economics that do not work: a fully-utilised, steady workload on recently-purchased hardware, especially with per-core licensing.
• A short remaining life: a system being replaced in a year should not be migrated to be decommissioned.
• Regulatory constraints that cannot be satisfied in the available regions.
• Unacceptable latency to a component that cannot move.

Record each decision properly, because otherwise it will be revisited annually by people who do not know it was already investigated. A useful entry states:

• the workload and its owner;
• the reason it is not moving, specifically — "a USB licence dongle" rather than "technical constraints";
• what would have to change for the answer to be different — a vendor upgrade, a licence model change, a hardware refresh date;
• when to look again.

That last field is what makes this a decision rather than a refusal. These entries also feed the retire and repurchase outcomes in the next lesson: a workload that cannot move and has no future is a candidate for replacement rather than for permanent exception.

What to take into the exam

• Observe dependencies, do not ask for them. Inbound connections and infrequent jobs are what get missed; observe long enough to see monthly work.
• Compatibility must hold at three layers: provider support, vendor support, and architecture.
• Do not upgrade during a migration. Two changes, two possible causes.
• Dongles, MAC-bound licences and specialist hardware are genuine blockers, not engineering problems for cutover night.
• Latency-bound pairs move together, which is what defines migration waves.
• Deciding not to move is a valid answer. Record the specific reason and what would have to change.