Hybrid workload migration is not just moving systems. It is deciding the safest order of change.
Most hybrid infrastructure migration risk does not come from the target platform. It comes from the path between the current estate and the target state. Some workloads need to stay local. Some can move to Azure. Some need to move onto Azure Local, Nutanix or another HCI platform. Some may use Azure VMware Solution as a bridge. Some should be retired or replaced rather than migrated. Some need to wait until dependencies, backup, identity, networking or application ownership are clearer. The migration succeeds when the order is right.
See how the safest order is decidedWhat hybrid infrastructure workload migration actually involves; the placement matrix behind every migration; which workloads should not move yet; how to group workloads into dependency-based waves; how the migration path changes per target platform; how to design coexistence, cutover and rollback; how backup, recovery, identity, network and security dependencies change during migration; why cloud and local foundations must exist before production moves; and a practical migration sequence. This guide is for organisations moving workloads across local infrastructure, VMware, Azure Local, Nutanix, Proxmox, AVS and Azure without turning platform change into production risk.
The migration sequence should follow the workload logic, not the renewal deadline.
A renewal date, hardware lifecycle date, data centre deadline or cloud target can force urgency. It should not decide the migration sequence by itself.
Hybrid workload migration needs discipline because the estate is rarely clean. Applications depend on files, databases, identity, network paths, local services, backup jobs, firewall rules, users, vendors and undocumented operational habits. Move the wrong workload first and the project becomes unstable. Move the right workload first and the estate starts to separate into clearer groups: what stays local, what moves to cloud, what needs HCI, what needs a bridge, what waits, and what should not be carried forward.
The value is not only the destination. It is the controlled path to the destination. Sequencing is the benefit; coexistence complexity is the trade-off.
Hybrid migration is the controlled movement of workloads across local, cloud and bridge platforms.
In practice it can involve:
- Moving VMware workloads to Azure Local or Nutanix
- Moving selected workloads to Azure
- Using Azure VMware Solution as a bridge
- Retaining some workloads on local infrastructure
- Refreshing local infrastructure before migration
- Retiring or replacing workloads that no longer deserve a platform
- Staging workloads over time because dependencies are not ready
- Operating local and cloud environments together during coexistence
The placement decision behind every migration.
Before sequencing, each workload should be assigned a destination. The same set of variables decides whether a workload should stay local, move now, move later, or be retired or refactored — and applying them consistently is what turns a server list into a migration plan.
- Workload fit — strong local dependency or latency/sovereignty requirement
- Lifecycle timing — refresh cycle aligns to local HCI investment
- Migration risk — risk of moving is too high to justify the benefit
- Commercial model — on-prem cost is lower or cloud cost not justified
- Operating model — current team runs it locally after refresh
- Support posture — existing local support model continues
- Workload fit — self-contained, cloud-compatible, no tight local coupling
- Lifecycle timing — no timing constraint blocking migration
- Migration risk — low complexity, rollback is clean if needed
- Commercial model — cloud cost justified by operational benefit
- Operating model — team is ready to operate in cloud model post-cutover
- Support posture — cloud support model confirmed and ready
- Workload fit — cloud-appropriate but dependencies block immediate move
- Lifecycle timing — contract, vendor or platform timing not yet aligned
- Migration risk — high risk now, manageable once dependencies are resolved
- Commercial model — cloud economics viable when the workload is ready
- Operating model — operating model transition needs preparation time
- Support posture — current support continues until destination is ready
- Workload fit — does not fit any destination well as currently designed
- Lifecycle timing — near end of useful life: decommission is the timing answer
- Migration risk — migration would lock in a design that should be replaced
- Commercial model — cost of maintaining exceeds remaining useful value
- Operating model — removed from the operating model: no ongoing ownership needed
- Support posture — decommission and wind-down plan required
The full per-workload placement framework sits on the workload placement page; this matrix is the migration-sequencing view of the same logic.
When this becomes the right topic.
Workload migration becomes the issue when the platform decision is clear enough to move, but not simple enough to cut over all at once. This topic usually matters when:
- VMware renewal pressure has triggered a platform review
- Ageing servers need replacement but not every workload should stay local
- Azure Local or Nutanix has been selected for retained local workloads
- Some workloads are ready for Azure while others are not
- Azure VMware Solution is being considered as a temporary bridge
- A data centre or hosting exit creates timing pressure
- Backup and recovery need to be redesigned before migration
- Dependencies are not fully mapped
- Business outage tolerance is low
- Migration needs to happen in waves rather than one cutover
The common thread is complexity. The estate can move, but only if the migration path is designed properly. Related reading: VMware exit strategy, server replacement strategy, Azure vs on-prem vs hybrid and Azure VMware Solution.
The first decision is what does not move yet.
The instinct is often to ask what can move first. That matters, but the better starting point is what cannot move safely yet. Some workloads need special handling because of:
- Undocumented dependencies
- Vendor-controlled applications
- Tight database or file dependencies
- Latency-sensitive operation
- Identity or authentication coupling
- Hard-coded IP addresses
- Firewall and network path complexity
- Backup and recovery uncertainty
- Unsupported operating systems
- Application owners who cannot validate quickly
- Business processes that cannot tolerate outage
- Licensing tied to hardware, MAC address or environment
Workloads need to be grouped before they are moved.
Migration waves should follow dependency groups, not server lists. A server inventory is not a migration plan — a proper plan groups workloads by dependency, risk, business impact and target platform.
Clear ownership, limited dependencies, strong backup, lower business impact and a straightforward target path. They are useful for proving the migration process before higher-risk workloads move.
Still need local performance, data proximity, site dependency or predictable access. They may move to refreshed local infrastructure, Azure Local, Nutanix, Proxmox or another retained local platform.
Suitable for Azure, Microsoft 365, SaaS or managed cloud services. They should move only after cloud foundation, identity, security, backup, monitoring and cost ownership are in place.
May use Azure VMware Solution, temporary VMware retention or staged coexistence because re-platforming is too risky in the current window.
Should not be migrated at all. A migration is often the right time to identify systems that should be decommissioned, consolidated or replaced rather than carried forward.
The migration path depends on the target pattern.
Hybrid workload migration usually involves more than one destination, and the method should change depending on where the workload is going.
Usually part of infrastructure refresh or VMware exit. The migration needs to consider Microsoft alignment, HCI readiness, backup tooling, guest operating systems, workload performance, Azure Arc management and support ownership after cutover. See Azure Local HCI.
Suits estates where mature HCI, private cloud operations and Prism-based management are the better fit. The migration needs to consider AHV/AOS/Prism operations, support boundaries, backup compatibility and lifecycle ownership. See Nutanix AHV.
Can reduce licensing cost where the organisation has the Linux and operational capability to run Proxmox properly. The migration needs to consider ESXi import tooling, storage architecture, backup, HA, Australian support coverage and patching discipline. See Proxmox VE.
Usually a bridge. AVS can preserve more of the VMware operating model while moving workloads into Azure data centres, but it should have a defined Phase 2 plan. See Azure VMware Solution.
Suits workloads that genuinely benefit from Azure infrastructure or managed services. The migration should not start until landing zone, identity, network, backup, security, monitoring, cost governance and support ownership are ready. See Managed Cloud and Migration, Azure migration strategy and Azure landing zones.
Moves some workloads from ageing local infrastructure to refreshed local infrastructure or HCI. This is still a migration even when the workload stays on-premises — cutover, rollback, backup and validation still need to be planned. See server replacement strategy.
Coexistence is where many hybrid migrations become difficult.
During migration, the business often runs old and new environments at the same time. Coexistence is not a small detail — for a period, users, applications, identity, backup, monitoring and network flows may span more than one platform, and that period needs design. A coexistence plan should cover:
- Routing between old and new environments
- DNS and name resolution
- Identity and authentication paths
- Firewall rules and segmentation
- Backup coverage across both environments
- Monitoring across both environments
- Application dependencies that cross platforms
- User access during transition
- The rollback path if cutover fails
- Vendor support while applications are split
- Documentation of what has moved and what has not
Cutover needs rollback, not optimism.
A migration plan without rollback is not a migration plan. Cutover planning needs to be specific: what changes, when it changes, who owns it, what is validated, how users are notified, and what happens if the workload does not behave as expected.
A strong cutover plan includes:
- Pre-cutover backup confirmation
- Dependency confirmation
- Owner and vendor availability
- Test results or pilot outcome
- User communication
- A change window
- A validation checklist
- A rollback trigger
- A rollback method
- Post-cutover monitoring
- A stabilisation owner
Rollback does not need to be dramatic — it needs to be real. For some workloads, rollback may mean reversing DNS or routing changes; for others, restoring from backup, reverting replication, or keeping the old platform running in parallel until validation is complete. The rollback path should be decided before the change window, not during the incident.
Backup and recovery need to be redesigned during migration.
Migration is one of the moments where backup coverage can become unclear. When workloads move across platforms, backup and recovery assumptions change — a VM moving from VMware to Azure Local, Nutanix, Proxmox, AVS or Azure may need different tooling, different restore procedures, different recovery order and different identity dependencies.
A strong migration plan should answer:
- Is the workload protected before migration, during migration and immediately after cutover?
- What recovery method applies on the new platform?
- What restores first?
- What identity systems are needed during recovery?
- Are immutable or offsite copies in place?
- Has recovery been tested?
- Who owns recovery after cutover?
Map identity, network and security dependencies before production moves.
Many migration issues are not workload issues — they are dependency issues. Applications rarely run alone; they depend on identity, DNS, file paths, certificates, service accounts, firewall rules, routing, VPNs, remote access, databases, storage, monitoring agents and backup processes. A hybrid migration should map:
- Identity and authentication dependencies
- Domain services and Entra ID dependencies
- DNS and DHCP dependencies
- Firewall and segmentation rules
- Site-to-site connectivity
- VPN, ExpressRoute or SD-WAN paths
- Application-to-database paths
- File share dependencies
- Certificate and service account dependencies
- Backup and monitoring agents
- Security tooling and alerting
- Administrator access and privilege model
If dependencies are not mapped, the migration plan is only a server movement plan.
The target foundations must exist before workloads move.
Hybrid migration should not push workloads into an unmanaged environment on either side. Whether the destination is cloud or a new local platform, the foundation comes before the first production workload.
- Tenant and subscription structure
- Landing zone design
- Entra ID and identity model
- Conditional Access and MFA
- Network connectivity
- Resource groups and management groups
- Backup and recovery design
- Microsoft Defender and security baseline
- Monitoring and alerting
- Cost governance
- Administrator roles and RBAC
- Documentation and support ownership
- Cluster design and storage layout
- Network design
- Host lifecycle
- Backup integration
- Monitoring and alerting
- Security baseline and patching process
- Firmware and driver management
- Operational documentation
- Support escalation
- The hardware and software support model
- Recovery and rollback procedures
A workload moved into cloud before the foundation is ready may be technically live but operationally unmanaged — that is not migration success. And moving workloads onto a new local platform without this foundation simply creates a newer version of the old operating problem.
A practical migration sequence.
The sequence should reduce risk while proving the target state. A typical hybrid workload migration sequence looks like this.
Review servers, virtualisation, applications, data, users, sites, network paths, backup, recovery, identity, licensing, vendors, support responsibilities and known pain points. The goal is to understand what is stable, what is fragile, what is ageing and what should not be carried forward.
Stay local, move to Azure, move to Microsoft 365 or SaaS, move to Azure Local, move to Nutanix, move to Proxmox, use AVS as a bridge, retain temporarily, or retire and replace.
Cloud landing zone and/or local platform — before production workloads move.
Prove the migration process, validation and rollback before higher-risk workloads follow.
With coexistence, backup, rollback and validation designed into each wave.
Monitoring, backup verification, documentation, cost review and clear support ownership after each cutover.
What good looks like after migration.
Each system running where it makes operational sense across Azure, Microsoft 365, local infrastructure, Azure Local, Nutanix, Proxmox, AVS or a staged hybrid model.
Old application, network, identity and storage dependencies reduced, documented or deliberately retained because they are still needed.
The business knows what can be restored, how quickly, in what order and with which dependencies.
Any remaining hybrid or staged state documented, monitored and owned.
Monitoring, alerting, backup, documentation and support ownership across the whole estate.
The business knows what should happen next: reduce AVS use, move more workloads to Azure, retire old systems, modernise local infrastructure, or maintain the hybrid model deliberately.
We treat migration as operating-risk work, not just platform movement.
Hybrid workload migration goes wrong when it is treated as a technical move only — the technical destination matters, but the operating path matters more.
We start with workload placement, so the migration sequence follows what each workload needs rather than a platform slogan or renewal deadline. We design coexistence and rollback upfront, including dependency mapping, cutover windows, rollback paths, validation and stabilisation. We connect cloud and local foundations, considering Azure, Microsoft 365, retained local infrastructure, HCI, backup, networking, identity and security together. We do not force every workload through the same path — some move, some stay local, some bridge, some wait, some should be retired or replaced.
And we can support the environment after migration: the work does not finish when the workloads are live, with ongoing support spanning monitoring, patching, backup oversight, lifecycle planning, documentation, escalation, cloud integration and security baseline management depending on managed service scope.
The safest migration is not the fastest single move. It is the one that separates workloads properly, builds the foundations first and keeps a way back.
If your migration plan lists servers and dates but not waves, rollback triggers or a coexistence design, it is a movement plan — not a migration plan.
Pressure-test the plan against a refresh review →Hybrid migration work becomes real when platform pressure and production risk meet.
In recent infrastructure and cloud work, migration sequencing mattered as much as the selected platform. A VMware exit required workload review, landing-option assessment, rollback planning and post-cutover stabilisation before production change. A hybrid Azure environment required some workloads to remain local because project data, finance systems and performance requirements made blanket cloud migration the wrong answer.
The lesson is consistent. The safest migration is not the fastest single move — it is the one that separates workloads properly, builds the target foundations first, moves in controlled stages and keeps support ownership clear after cutover. See the VMware exit and cloud migration case studies.
What this usually leads to next.
Hybrid workload migration usually sits between the decision and the delivery.
- If the migration is being driven by ageing infrastructure — the next step is usually Infrastructure Refresh.
- If VMware renewal is the trigger — see Broadcom VMware renewal and VMware exit strategy.
- If the issue is workload placement — see VMware workload placement and Azure vs on-prem vs hybrid.
- If the target state is cloud-heavy — see Managed Cloud and Migration, Azure migration strategy and Azure landing zones.
- If the target state is local HCI — see Azure Local HCI, Azure Local vs Nutanix, Nutanix AHV and Proxmox VE.
Common hybrid infrastructure and migration questions.
Should everything move at once?
What should move first?
What if dependencies are not mapped?
Do we need rollback for every workload?
Does backup change during migration?
What about coexistence?
Where does this sit in Inlight IT's Cloud and Infrastructure structure?
If you are heading hybrid, check the logic before production changes.
Sequence what moves and what waits, with a way back.
Talk through your infrastructure refresh options