Can You Prove This Workload Belongs in the Cloud?

The board approved the migration. Finance expects lower costs. IT expects fewer systems to manage.

But nobody answered the question that decides whether any of that happens.

Can you prove this workload belongs in the environment you’re moving it to?

Prove it by tying a specific requirement of this workload, its demand pattern, its data or latency limits, or what it depends on, to a measurable advantage of where it’s headed. If you can’t connect at least one hard requirement to a hard number, the decision hasn’t been proven yet, no matter how confident the business case sounds.

A migration can go perfectly and still be the wrong decision. Every server moves. Every deadline gets hit. Then eighteen months later the bill is higher, the team is doing the same work, or the workload gets moved again.

The organizational direction may already be set. The workload decision is not final yet. That’s true whether you’re planning a migration, defending one already approved, weighing repatriation, or heading into a renewal. The test is the same every time.

This framework comes out of a conversation with Jeremy Pease, CEO of Aptum, on where infrastructure decisions actually go wrong. For the full conversation behind it, listen to Did You Choose Cloud for the Wrong Reason?

Start with the problem, not the platform

Moving to cloud is not an objective. Neither is staying on prem. The objective is whatever you’re actually solving for: lower cost, unpredictable demand, latency, compliance, less staffing overhead, a new geography, faster deployment. Name the specific one. It determines what success looks like, and it’s the first thing missing from most infrastructure business cases.

Prove the workload actually benefits

Does demand actually change enough to justify elasticity? If your usage barely moves throughout the year, elasticity isn’t doing the work the business case is crediting it for. What to prove: pull twelve months of compute and utilization data. Identify normal load, peak load, how often peaks happen, how long they last, and how much capacity sits unused the rest of the time.

What crosses the network, and where does it go? A cheap compute comparison can become an expensive architecture once you price the traffic around it. What to prove: map what enters and leaves the application, where it goes, how often, and what latency it can tolerate, before comparing a single infrastructure price.

What constraint on this workload can’t move? Sometimes the decision isn’t about benefits. It’s about constraints. Latency requirements, data location rules, recovery objectives, licensing terms, hardware dependencies, and integration requirements can rule out an environment before cost ever enters the conversation. What to prove: list every constraint that isn’t negotiable, and confirm the destination actually satisfies each one, not just the popular ones.

What stays behind? A workload doesn’t exist alone. Databases, identity systems, file systems, third party integrations, backups, other applications, and the people who use it all have their own location. What to prove: map every system this application talks to and where each one will actually live after the move. A technically clean migration can still create a worse application if the systems it depends on stay somewhere else.

Prove the move changes the economics

What operational work actually disappears? Lifting servers into someone else’s data center doesn’t automatically remove patching, monitoring, and security work if the architecture underneath doesn’t change. What to prove: name the specific responsibilities that go away. If you can’t name them, the savings haven’t been demonstrated.

What does it actually cost to run this workload in each environment? Divide the comparison into four groups: costs that disappear, costs that stay, costs that increase, and costs that are new. If your team still patches the operating system after the move, don’t count that labor as savings. If eighteen months remain on the current data center contract, that expense doesn’t vanish on migration day. If network traffic becomes billable in the new environment, price it before comparing compute costs.

What comes from migration, and what only comes from redesign? Buyers routinely blur these two.

Migration gives you	Redesign may give you
A different infrastructure location	A different operating model
A different consumption model	Autoscaling built into the application
A new provider or toolset	Managed services
Possibly a different cost structure	Less server management
The same application architecture	An actual architectural change

Don’t put benefits from the second column into the business case if you’re only funding the first.

The same applies to compliance. A provider being compliant and this specific workload meeting your requirements inside that environment are two different statements. Identify the actual controls required, where the data has to sit, what evidence an auditor will want, what responsibility your organization retains regardless of provider, and any requirement specific to this application, before assuming the environment covers you.

Decide what failure looks like before you move

Define the conditions that would make you reverse this decision, and decide now when you’ll check them. Otherwise the thresholds get written down once and forgotten.

Your thresholds will depend on the workload. For example: cost running more than fifteen percent above the model for three consecutive months. Latency exceeding the agreed threshold. Operational workload that hasn’t dropped after six months. Required controls that get harder or more expensive to maintain.

Set a review at ninety days, and again before the next renewal or commitment. A threshold nobody revisits isn’t governance. It’s a sentence you wrote once and moved on from.

The workload decision sheet

Question	Answer
We’re moving this application because
The workload requirement driving the decision is
The measurable improvement we expect is
The evidence supporting that assumption is
Full annual cost today is
Full annual cost afterward is
Operational work that disappears is
New costs or dependencies we’re accepting are
We’ll reconsider this decision if
We’ll review the result on

If you can’t fill that out, you don’t have an infrastructure decision yet. You have a destination someone else picked for you.

Vendors aren’t going to hand you this test, because most of them are selling the destination, not the fit. Someone on your side of the table asks what the workload actually needs before asking where it should live.

If a board initiative is what’s putting this decision in front of you right now, this is where to start. It covers what’s actually at stake in that kind of mandate and what independent representation changes about the outcome.

This test applies whether the migration is still open for debate, already approved, or already in place and something feels off. It works before the next move, not after.

Before vendors shape the direction. That’s when Strategy matters most. Get Started.

No pitch. No prep. Just answers.