What should stay on-premises, what should move to cloud, and what should not be decided all at once?
Most infrastructure decisions are not really on-premises versus cloud. They are workload placement decisions. Some workloads still belong on local infrastructure. Some clearly benefit from Azure, Microsoft 365 or SaaS. Others only make sense as part of a staged or hybrid model — especially when the estate is tied to VMware, ageing servers, local dependencies or business-critical systems that cannot be moved casually. The right answer depends on latency, data gravity, data residency, commercial logic, operating model, resilience requirements, migration risk and how tightly the workload needs to stay connected to local systems.
See how the placement decision worksWhich workloads should stay on local infrastructure; which should move to Azure, Microsoft 365 or SaaS; which need a hybrid or staged path; how cost logic changes with workload shape; the placement questions to apply workload by workload; the evidence to gather before deciding; quick placement signals by workload type; and the placement mistakes that force reversals later. This guide is for organisations reviewing VMware estates, ageing servers or hybrid direction who want a defensible workload map before the platform decision is made.
This is not a platform argument. It is a workload placement exercise.
One of the most common infrastructure mistakes is trying to decide whether the whole estate should stay on-premises or move to cloud. In practice, most organisations do not have one uniform workload pattern. They have a mix of local dependencies, steady-state systems, cloud-suitable services, legacy applications, data-heavy workloads, infrastructure services, collaboration platforms and workloads that need a staged transition.
That is why the strongest answer is often hybrid. Not hybrid as a compromise — hybrid as the practical result of assessing workloads properly. The goal is not to defend local infrastructure against cloud, and not to move everything to cloud because cloud sounds modern. It is to place each workload where it works best technically, commercially and operationally.
Stay local, move to cloud, or use a staged hybrid path depending on what the workload needs.
- Stay on local infrastructure — when low latency, local system dependency, data residency, limited connectivity, large data movement, predictable utilisation or local processing requirements materially shape the operating model. This may include workloads connected to plant, sites, clinics, branches, project data, local file access, finance systems or operational platforms that perform best close to users or equipment.
- Move to cloud — when elasticity, managed services, rapid scaling, geographic reach, modernisation opportunity or reduced infrastructure management create a real advantage over fixed local infrastructure. This may include workloads suited to Azure services, Microsoft 365, SaaS, managed databases, internet-facing services, development environments or workloads being redesigned anyway.
- Use hybrid or staged placement — when neither local nor cloud is right for the whole estate. This is common when some workloads need local performance while others benefit from Azure, Microsoft 365 or managed cloud operations — and when VMware exit, infrastructure refresh and cloud migration timelines overlap.
What usually stays on local infrastructure.
Keeping a workload local is usually the better answer when it depends heavily on local systems, needs consistently low latency, or must remain under tighter operational control. Retaining workloads locally is not the same as resisting change — in many environments it is the technically and commercially correct decision. Local infrastructure is often the better fit for:
- Core infrastructure services with strong local dependency
- Workloads tightly integrated with on-site systems, plant, equipment or branch operations
- Latency-sensitive applications that perform best close to the point of use
- High-volume file services with heavy local access patterns
- Workloads with data residency, contractual or control requirements
- Locations with limited or inconsistent connectivity
- Predictable steady-state workloads where fixed local infrastructure remains commercially sensible
- Workloads where cloud egress or data movement would create avoidable cost or complexity
- Systems that need staged migration because dependencies are not yet cleanly separated
For these workloads, the better question is not whether local infrastructure is old. It is whether the local platform should be refreshed, modernised to HCI, moved to Azure Local or Nutanix, or retained temporarily while other workloads move. Related reading: server replacement strategy, Azure Local HCI and Azure Local vs Nutanix.
What usually moves to cloud.
Moving a workload to cloud is usually the better answer when it benefits from elastic scaling, managed platform services, broader geographic reach or reduced hands-on infrastructure management. Cloud is not the default for every workload — it is the right answer for workloads that genuinely benefit from managed services, elastic capacity, modernisation or improved access. Cloud is often the better fit for:
- Workloads with variable or bursty demand
- Applications that need rapid scaling up and down
- Workloads already being modernised or re-architected
- Services suited to managed databases, platform services or SaaS
- Internet-facing applications where geographic reach or resilience matters
- Environments where reducing baseline infrastructure management is a genuine priority
- Collaboration, identity and document workloads that fit Microsoft 365 or Entra ID
- Workloads where cloud backup, disaster recovery or geographic flexibility improves the operating model
For these workloads, the question is not whether the business can move them. It is whether the cloud foundation is ready: identity, access, networking, monitoring, security, backup, cost governance and support ownership. Related reading: Managed Cloud and Migration, Azure migration strategy and Azure landing zones.
What usually needs hybrid or staged placement.
A lot of workloads do not belong fully in either bucket. Many environments need a hybrid answer — not because the organisation is indecisive, but because the workload mix genuinely spans local and cloud requirements. The strongest hybrid models are not created by moving the easiest workloads blindly; they are created by deciding what belongs where before migration begins. Hybrid or staged placement is often right for:
- Production environments with tightly coupled legacy and modern systems
- Applications that need local control but benefit from cloud-connected management
- Estates moving off VMware in stages rather than all at once
- Environments where some workloads belong on a modern local platform and others fit Azure
- Organisations that need to protect production operations while changing platform direction
- Workloads where backup, recovery, identity or networking needs to be redesigned before migration
- Environments where the target state is clear, but the safe migration sequence needs time
This is where VMware workload placement usually becomes part of a broader Infrastructure Refresh decision: refresh local infrastructure for workloads that still need to remain local, move selected workloads to cloud, and stage the remainder through a controlled migration plan. Related reading: VMware exit strategy, hybrid infrastructure workload migration and Azure vs on-prem vs hybrid.
Cost logic only becomes useful when it is tied to workload shape.
Do not assume cloud is automatically cheaper or that on-premises is automatically more efficient. Some steady-state workloads remain commercially sensible on local infrastructure. Some variable workloads become more efficient in cloud because capacity can scale with demand. Some data-heavy workloads become less attractive in cloud when egress, inter-region movement or persistent consumption costs are factored properly. High-egress and data-gravity workloads should not be moved on generic cloud-cost assumptions alone.
- Predictable steady-state utilisation
- High-egress data patterns
- Large file access close to users or equipment
- Existing hardware that remains supportable
- Workloads where local performance materially reduces support issues
- Licensing positions that are more efficient in local or hybrid models
- Workloads where fixed infrastructure is already well-utilised
- Variable or bursty demand
- Managed services that reduce operational overhead
- Workloads where pay-as-you-go scaling reduces wasted capacity
- Services that benefit from geographic availability
- Workloads being modernised or replaced
- Environments where reducing infrastructure ownership is a genuine business priority
The worst cost decision is comparing a fully loaded local environment against a cloud estimate that excludes networking, backup, security, support, data movement and operational ownership.
Workload placement should be decided workload by workload.
A good workload placement review does not begin with a destination. It begins with a consistent set of questions, applied to each major workload.
Does the workload need to stay physically close to users, systems, equipment, files or data sources? Latency-sensitive workloads often perform better locally or on a modern local platform.
How tightly is the workload tied to on-site infrastructure, data flows, plant systems, branch operations or local applications? The tighter the dependency, the more carefully cloud movement needs to be staged.
Are there residency, control, contractual, client or regulatory requirements that shape where the workload can run? Location alone does not solve governance, but it can materially affect the placement decision.
Does the workload need to scale up and down materially over time? Elastic demand often supports cloud placement; predictable steady-state demand may not.
Does the organisation want to reduce baseline infrastructure management through managed services? Some workloads become stronger cloud candidates when managed services reduce patching, platform maintenance, backup complexity or operational overhead.
Will the workload create meaningful egress, replication or transfer cost? Data-heavy workloads need cost modelling before being moved on a cloud-first assumption.
Is the workload simple to move, or does it need staged transition, coexistence and rollback planning? The higher the migration risk, the more likely the workload needs a staged or bridge path.
What will be easier to support after cutover? A technically valid destination is not enough — the final placement needs to be monitored, patched, secured, backed up, documented and supported.
Evidence to gather before deciding.
Placement decisions made without evidence tend to be reversed or regretted. Before deciding what stays local and what moves, the review should gather:
- Dependency map — what each workload talks to and what it requires to function
- Data sensitivity classification — residency, contractual, client or regulatory constraints
- Bandwidth and latency measurements — actual conditions between sites, users and cloud regions
- Vendor and support agreements — any constraints around where the workload can run
- Current utilisation and demand profile — steady-state, variable, seasonal or elastic
- Recovery posture — backup coverage, RTO expectations and last-tested restore date
- Licensing position — whether the move changes software, hypervisor or cloud economics
- Support model — who will operate the workload after the move
Quick placement signals by workload type.
The signal is not the final answer, but it shows where the review usually starts.
- Domain services, AD, DNS and core infrastructure — often local or hybrid because of dependency and latency
- High-volume file services — often local or hybrid because of egress, latency and user experience
- Predictable steady-state databases — often local unless managed database services are operationally justified
- Development and test workloads — often cloud because elastic and disposable capacity can reduce waste
- Backup and disaster recovery — often hybrid because local recovery and offsite resilience both matter
- Customer-facing applications — often cloud where resilience, scale or geographic reach justifies it
- Legacy applications with no cloud path — often local or staged because the application is not cloud-ready
- Microsoft 365 collaboration workloads — cloud, but only with information architecture, permissions and backup considered
- VMware workloads under renewal pressure — mixed: retain, move, stage, bridge or retire depending on workload fit
This is why a VMware exit strategy should not start with “which platform replaces VMware?” It should start with which workloads still deserve a local platform, which belong in cloud, and which should not be carried forward at all.
Most poor placement decisions come from forcing a philosophy onto the estate.
The two most common mistakes point in opposite directions.
This can create performance issues, higher-than-expected cost, new backup complexity, security drift, user frustration and a support model that nobody clearly owns. Cloud migration can be the right answer for many workloads. It is not the right answer for all workloads.
This can lead to unnecessary hardware spend, ageing infrastructure risk, missed managed-service benefits and workloads remaining on platforms they no longer need. Local infrastructure can be the right answer — it should be a deliberate one.
Usually too blunt. Some VMware workloads may be strong candidates for Azure Local or Nutanix, others may move to Azure, others may need a bridge path such as Azure VMware Solution, and others may be retired or replaced.
This misses the real question. It is not only where the workload runs — it is who operates it, how it is monitored, how it is backed up, how it is recovered, how access is controlled, and how cost is governed after the change.
For many organisations, the right answer is a better-designed hybrid model.
Keep workloads local when local control, low latency, data residency, operational dependency or predictable economics make local placement the better fit. Move workloads to cloud when elasticity, managed services, modernisation or broader cloud-native advantages materially improve the operating model. Use hybrid when the estate includes both types of requirement, which is common in real environments.
The goal is not to defend one location against the other. It is to place each workload where it works best commercially, operationally and technically. Inlight IT assesses workload placement as part of Infrastructure Refresh, VMware exit and Managed Cloud and Migration work — the recommendation is not to move everything to one destination, but to map each workload to the platform that fits its technical, commercial and operational reality.
Hybrid is not a failure to choose. It is often the correct result of choosing properly.
If you cannot yet say which workloads would stay local and which would move — and why — the estate has a platform preference, not a placement map.
Build the map into a refresh decision →What this usually leads to next.
Workload placement is rarely the final decision. It usually reveals a downstream question that needs working through before migration begins.
- If many workloads still need to remain local — the next question is usually Infrastructure Refresh: modernise the local platform, review HCI options, assess Azure Local or Nutanix, and improve backup, recovery and supportability. See Infrastructure Refresh.
- If VMware renewal is driving the review — the next question is whether to renew, reduce, stage, bridge or move selected workloads away from VMware. See Broadcom VMware renewal and VMware exit strategy.
- If some workloads are cloud-ready — the next question is usually the cloud foundation before workloads move: identity, landing zone, backup, security, monitoring, cost governance and support ownership. See Managed Cloud and Migration.
- If the answer is mixed — the next question is usually hybrid migration sequencing: which workloads move first, what stays local, what requires a bridge path, and where rollback needs to be explicit. See Hybrid infrastructure workload migration.
Workload placement becomes real when renewal pressure, local dependencies and migration risk meet.
In a recent production environment affected by VMware licensing pressure, Inlight IT assessed which workloads should remain on local infrastructure, which were better suited to cloud-connected or cloud-hosted paths, and how migration sequencing could be shaped without increasing production risk. The value in this kind of work is not simply choosing a destination — it is giving the business a defensible workload map before the platform decision is made: what stays, what moves, what stages, what waits, and what should not be carried forward. See the related VMware exit case study.
A placement decision should leave the business with a workload map, not a platform preference.
Most estates do not support one universal destination. Some workloads need local performance, operational control or proximity to users, equipment and data. Others benefit from Azure, Microsoft 365, managed services or elastic capacity. A third group needs a staged path because dependencies, recovery design or migration risk prevent a direct move.
The value of a workload placement review is the resulting map: what stays local, what moves, what stages, what retires and what should not be carried forward. That map should be supported by evidence about dependencies, latency, data movement, licensing, recovery, cost and post-cutover ownership. Hybrid is not an avoidance of the decision. In many environments, it is the deliberate result of making the decision workload by workload.
The destination is only half the decision. The other half is whether the workload can be migrated, recovered and operated there.
If one destination has been assigned to the whole estate before workloads have been classified, the organisation has chosen a platform direction, not completed a placement review.
Build the workload map →Common workload placement questions.
Is hybrid still a valid model, or should everything move to cloud?
What usually should stay on-premises?
What usually should move to cloud?
Is cloud always cheaper than on-premises?
Is on-premises always more secure or more controlled?
Should the whole VMware estate be moved or retained as one decision?
Does workload placement happen before VMware exit strategy?
Where does this sit in Inlight IT's Cloud and Infrastructure structure?
Start with the workload decision, before the migration or refresh.
Not every workload needs the same answer or home.
Talk through your infrastructure refresh options