CONSULT CIRCLE | CLOUD MIGRATION
A decision framework for placing workloads, the costs both sides of the argument ignore, and the criteria that actually predict a good outcome.
The hybrid cloud debate is usually conducted as an argument about principle. One side says cloud is more agile and the datacentre is a liability. The other says cloud is expensive and control matters. Both are describing real experiences, and both generalise from them further than the evidence supports.
Workload placement is not a philosophy. It is a per-workload decision with a small number of inputs, and most organisations get better results by applying a consistent framework than by picking a side. This guide sets out the criteria that actually predict whether a workload will do well in cloud, the ones that predict it should stay put, and the costs each camp routinely leaves out of the comparison.
What this guide covers
- Starting with the workload rather than the destination
- The costs each side of the argument leaves out
- A ten-question placement decision framework
- Four hybrid placement patterns that work
- What makes hybrid estates hard to operate, and the common mistakes
Start with the workload, not the destination
A cloud-first or cloud-never policy applied estate-wide guarantees that some workloads end up in the wrong place. The useful question is never "should we be in the cloud" but "where does this specific workload belong, given how it behaves and what it costs".
Five characteristics do most of the predictive work.
| Characteristic | Points towards cloud | Points towards on-premises |
|---|---|---|
| Demand pattern | Variable, spiky, seasonal or growing unpredictably. You pay for what you use and scale without procurement | Flat and predictable. Steady-state consumption is where owned capacity is usually cheaper over a refresh cycle |
| Data gravity | Data is already in cloud, or is generated there | Large datasets queried constantly by on-premises systems. Moving compute to data beats moving data to compute |
| Change rate | Actively developed, frequently deployed, benefits from managed services | Stable, rarely changed, works as it is. Migration cost has nothing to amortise against |
| Latency and locality | Users and integrations are distributed or already cloud-based | Deterministic low latency to plant, devices, trading systems or local storage |
| Regulatory position | Requirements can be met with cloud controls and documented residency | Hard data residency, sovereignty or contractual constraints that cloud cannot satisfy |
Table 1 - Workload characteristics and what they indicate.
The costs each side leaves out
Most placement business cases are wrong in predictable directions.
What cloud proposals routinely omit
- Egress charges, which only become visible once real traffic patterns emerge.
- The cost of running steady-state workloads at on-demand rates because nobody bought reservations.
- Parallel running during migration, which for a large estate can mean carrying both environments for the better part of a year.
- Re-skilling, and the productivity dip while it happens.
- Tooling replacement, since backup, monitoring and security products rarely transfer unchanged.
What on-premises proposals routinely omit
- Refresh capital on a three to five year cycle, often compared against cloud opex as though it were free.
- Power, cooling, rack space and the facility itself, especially where these sit in another department''s budget.
- The cost of capacity bought for peak and idle the rest of the time.
- Staff time on patching, firmware, hardware faults and lifecycle work that a managed service would absorb.
- Disaster recovery capacity, which is frequently under-provisioned rather than genuinely cheaper.
A placement decision framework
Score each workload against these questions. The pattern of answers usually makes the decision obvious, and where it does not, the workload is genuinely marginal and should stay where it is until something changes.
- Is demand variable enough that elasticity has real value, or is consumption effectively flat?
- Where does the data live, how large is it, and what talks to it most frequently?
- Is this workload actively developed, or stable and rarely touched?
- What latency does it require, and to what?
- Are there residency, sovereignty or contractual constraints that narrow the options?
- What does it depend on, and would migrating it split a tightly coupled group?
- What is the licensing position, and does it change on different infrastructure?
- Who supports it, and do they have the skills for the target platform?
- What is the cost over a full refresh cycle in each location, including the omissions above?
- If this goes wrong, what is the rollback, and how long is it available?
Where the answers point to movement, the next decision is which of the six migration strategies applies. That is covered in How to Choose the Right Cloud Migration Strategy for Your Legacy Applications.
Four placement patterns that work
| Pattern | What it looks like | Suits |
|---|---|---|
| Cloud for elastic, on-premises for baseline | Predictable steady-state capacity stays owned; burst, dev/test and seasonal load runs in cloud | Organisations with a stable core and genuinely variable peaks |
| Cloud for new, on-premises until refresh | Nothing new is built on-premises; existing workloads move as hardware reaches end of life | Estates with staggered refresh cycles and no forcing event |
| Cloud for the estate, on-premises for the exceptions | A deliberate, documented list of workloads that stay, with the reason recorded | Datacentre exits, where the default has to be movement |
| Hosted private cloud as the middle ground | VMware-based private cloud in a colocation or hyperscaler platform, keeping operational consistency | Organisations needing cloud economics without re-platforming applications |
Table 2 - Common hybrid placement patterns.
What makes hybrid hard to operate
Placement decisions are the easy part. Running the result is where hybrid estates get expensive.
- Two of everything. Two monitoring stacks, two backup products, two identity models and two sets of runbooks is the default outcome, and it doubles operational load. Consolidating tooling across both environments is worth more than most placement optimisation - our Monitoring as a Service covers both sides from one place.
- Networking between the halves. Bandwidth, latency and cost of the interconnect shape what can sensibly be split. Chatty applications separated across the boundary perform badly and generate egress.
- Identity sprawl. One identity plane across both environments is a prerequisite, not a refinement. Two directories with partial sync is where security incidents originate.
- Inconsistent security posture. Controls that exist in one environment and not the other create a predictable weak side, and auditors find it.
- Split resilience. A hybrid estate needs one recovery plan, not two. See BC/DR Planning and Disaster Recovery Services.
Common mistakes
- Deciding placement by policy rather than per workload, then discovering the exceptions late.
- Lifting and shifting a chatty application into cloud without addressing how it talks to what stayed behind.
- Modelling cloud cost on provisioned capacity rather than on right-sized consumption with reservations.
- Splitting a tightly coupled application group across the boundary because the individual workloads looked movable.
- Treating the migration as the end state, then never right-sizing afterwards.
- Running two complete tooling stacks indefinitely because consolidation was never scheduled.
Where to go next
- Practical Cloud Migration Checklist: 10 Steps to Reduce Risk and Cost
- How to Choose the Right Cloud Migration Strategy for Your Legacy Applications
- 3 Quick Signs Your Business Is Ready to Move Non-Critical Workloads to the Cloud
- VCF Migration Services for hosted private cloud and datacentre exit programmes.
Frequently Asked Questions
What is hybrid cloud architecture?
An architecture where workloads run across both on-premises infrastructure and public or hosted cloud platforms, with connectivity, identity and management spanning both. The aim is to place each workload where it performs and costs best rather than standardising on one location.
Is hybrid cloud cheaper than public cloud?
It can be for steady-state workloads, because predictable consumption is usually cheaper on owned or reserved capacity. It is rarely cheaper for variable workloads, and it costs more to operate because you are running two environments. The economics depend on your demand pattern.
Which workloads should stay on-premises?
Those with flat, predictable demand, large datasets queried by local systems, hard latency requirements, strict data residency constraints, or that are stable and rarely changed so migration cost has nothing to amortise against.
How do I decide what to migrate first?
Start with workloads that are low-risk, have few dependencies and a clear owner who can test and accept them. The first wave is about proving the process and the landing zone, not about maximising value.
What is the biggest hidden cost in hybrid cloud?
Operational duplication. Two monitoring stacks, two backup products, two identity models and two sets of runbooks. It rarely appears in the business case and it persists for years.
Talk to Consult Circle
If you are working through workload placement, we run fixed-fee assessments that produce a scored per-workload recommendation with a costed comparison across a full refresh cycle. Book a free 30-minute call - 0203 916 5593 - info@consultcircle.com