A hybrid architecture combines owned infrastructure with public cloud services and splits workloads between them according to what each one needs. It is not a waypoint on the road to full cloud: for many operations it is the destination, and it pays to design it that way from the outset.
Below: the criteria that decide where a workload goes, the three possible answers rather than two, why hybrid persists, what makes it expensive when improvised, and how the decision is ordered.
The question a cloud programme usually opens with — "when do we migrate everything?" — carries a hidden assumption: that moving everything is the objective. In most operations it is not, and discovering that late is expensive.
The useful question is different: what does each workload gain by moving, and what does it lose. The answer is rarely the same for all of them, and an estate of forty applications will not produce one verdict however much a board would prefer it did.
The criteria that decide where a workload goes
How its demand varies. A workload with sharp peaks — month-end, high season — gains a great deal from being able to grow and shrink. A stable, predictable workload gains considerably less, and that is the case where cost can rise on moving.
How tightly coupled it is. A system in constant conversation with others that stay behind produces round-trip traffic that is paid for and noticed. The latency between two components that used to sit together changes how the application behaves.
What the regulation requires. Certain information may carry requirements about where it resides or how it is held. That is a design constraint, not a later formality.
How much life it has left. Moving an application due for replacement in eighteen months is work that gets discarded along with the application itself.
Three possible answers, not two
The conversation is usually framed as move or do not move, and that binary hides the option most used in practice. There are three answers: move as it is, redesign then move, or leave it where it is.
The first is quick and preserves the defects: it serves when the objective is exiting a data centre against a deadline. The second is what produces the benefits promised in presentations — real elasticity, cost proportional to use — and costs considerably more.
The third is a legitimate decision that almost never gets written down, which is why it gets revisited in meeting after meeting. Recording it, with its reason, saves that cycle.
Why hybrid persists
It gets presented as a transition because that sounds orderly, but the reasons that keep a workload at home do not usually expire. A system that cannot move by design will still not move next year; a regulatory constraint does not disappear because it was planned around.
Accepting that has an important practical consequence: if hybrid is permanent, then connectivity between both worlds, shared identity and a unified operating model stop being provisional and deserve real investment. Treating them as a patch is what makes the model expensive.
What makes it expensive when improvised
Three things, and none appears in the initial estimate. The first is traffic between environments: moving data outward has a cost, and a chatty integration multiplies it without anybody noticing until the invoice.
The second is duplicated operations: two ways to monitor, two to back up, two to grant access. The team ends up maintaining two disciplines instead of one.
The third is fragmented identity. When each environment manages its own users, access control degrades and permission review becomes a manual exercise nobody completes.
The cost comparison that is usually wrong
Most hybrid business cases compare the monthly invoice against the depreciation of owned hardware, and that comparison flatters whichever side the author already preferred. It leaves out the two things that actually differ.
The first is what idle capacity costs. Owned infrastructure is sized for the peak and paid for at that size all year; cloud is paid for as used. A workload running at 30 % of its ceiling for eleven months is quietly funding capacity it touches in December, and that gap never appears as a line item anywhere.
The second is what the team spends its time on. Patching, replacing failed disks and planning capacity are real hours that do not vanish when the invoice is compared. They move rather than disappear — cloud replaces them with cost governance and access management — but a comparison that counts hours on one side and not the other is not a comparison.
The honest version prices both sides on the same basis over three years, including the migration itself, and states plainly which workloads it covers. A single blended number across a mixed estate answers nothing.
How the decision is ordered
With an inventory of workloads and four columns: demand variability, coupling, constraints and remaining life. Nothing more is needed to separate what is worth moving, what needs redesigning first, and what stays.
That inventory, with real cost at the destination, is what a cloud readiness assessment produces. It includes something estimates usually omit: the spend that appears after migrating and was not in the original comparison.
Where the data sits changes the shortlist
For an operation in Colombia or Mexico there is a constraint that reorders the criteria above: some information carries requirements about where it may reside, and that is settled before anything else is weighed.
It has a practical consequence people meet late. Not every cloud service exists in every region, so a workload that must stay in-country may find the managed database or the analytics service it was designed around is simply unavailable there. The design then either changes or the residency requirement does, and discovering which after the migration plan is signed is the expensive path.
Checking service availability against the shortlist of regions costs an afternoon. It belongs next to the workload inventory rather than after it.
What has to be built either way
Whatever the split, three capabilities hold the model together: a single identity across both environments, a common way to observe what is happening, and one criterion for backup and recovery.
Building them early makes moving an additional workload a simple decision rather than a project. It is the difference between a cloud capability and a collection of servers somewhere else. We support it from Bogotá and Mexico City, in the time zone of whoever runs the operation.
The order matters as much as the list. Identity first, because every later access decision inherits it and retrofitting one is a migration in itself. Observability second, since without it nothing that follows can be verified. Backup and recovery third, and tested rather than documented — a recovery procedure nobody has executed is a hypothesis, and the first time you test it should not be the day you need it.
Frequently asked questions
What is a hybrid cloud architecture?
One that combines owned infrastructure with public cloud services and splits workloads between them according to what each needs. For many operations it is the destination rather than a staging post, and it pays to design it that way.
Which workloads should move first?
Those with variable demand and low coupling to systems that stay behind. Stable, predictable ones gain less, and are the case where cost can actually rise on moving.
Why does cost sometimes go up after migrating?
Traffic between environments generated by a chatty integration, maintaining two ways of operating in parallel, and stable workloads that never use the elasticity. None of it appears in the initial estimate.
Is hybrid a temporary state?
Rarely. The reasons that keep a workload at home — coupled design, regulatory constraints — do not usually expire. Assuming it is permanent justifies investing properly in connectivity, identity and unified operations instead of patching them.
What are the three possible answers for a workload?
Move as it is, redesign then move, or leave it where it is. The third is legitimate and almost never written down, which is why it gets re-argued in meeting after meeting.
What has to exist regardless of the split?
A single identity across both environments, a common way to observe what is happening, and one criterion for backup and recovery. Without them, each additional workload is a project.
