Work Hours
Monday to Friday: 10.00 - 19.00
A cloud placement decision rarely fails in a way anyone notices. It expires quietly, while the workload keeps running and the bill arrives each month and nothing breaks. Underneath that stability, though, the conditions that shaped the original decision keep moving: usage, pricing, the available services, the compliance requirements. None of them sit still.
At some point, the decision stops describing the workload that exists and starts describing the workload that existed when someone last thought carefully about where it should run. That is not a failure. Placement decisions are made under specific conditions at a specific moment, and when those conditions change, the decision simply ages. Knowing when that has happened, and what to do about it, is ordinary infrastructure management rather than evidence that something went wrong.
We explored the architectural case for why placement is a first-order decision in our earlier piece on cloud cost and workload placement. This article picks up the next question: when does a placement decision actually need to be reviewed?
For business leaders, the question reaches past infrastructure. Placement shapes cost predictability, compliance exposure, performance, and how much of the team’s time goes into keeping systems stable, which makes the review cadence as much a business decision as a technical one.
What a placement decision actually captures
When a team decides where a workload should run, they are not only picking a provider or a region. They are making a judgement that folds several things together at once: how the workload behaves today, what it is expected to cost, what services and regions are available, what the compliance picture looks like, who owns it operationally, and what the team actually has the capacity to manage. Every one of those inputs is current at the moment the decision is made, and not one of them is guaranteed to stay that way.
So a placement decision is really a snapshot: of the workload, the pricing, the alternatives, and the regulatory context as they existed at a particular time. It holds up for as long as those inputs hold up. When they drift, and most of them will, the decision starts to age even though the workload keeps running exactly where it was told to run. The logic that put it there is what quietly stops applying.
The four things that move after the decision is made
Any of these can shift independently of the others. That is what makes placement decisions age without warning.
Workload behaviour changes
Workloads are not static. Something that was CPU-bound two years ago may be memory-heavy today; a service with predictable traffic may have turned bursty after a product launch; data that mostly sat at rest may now move constantly, which changes egress costs and upends the data-gravity assumptions baked into the original call. Product direction pushes this along too: features get added, integrations expand, and user geography shifts, so a workload placed to serve one region can end up serving three, with latency and sovereignty implications that simply did not exist before. The workload you placed two years ago is not always the workload running today.
Pricing and cost assumptions change
Cloud pricing is not fixed either. Commitment structures evolve, managed-service costs shift, storage-class economics change, and egress pricing, long one of the biggest variables in any placement decision, gets renegotiated or repackaged. New discount models appear while old ones expire or lose their edge. Meanwhile, the original cost model often sits untouched underneath the placement decision long after the landscape around it has moved, because teams rarely revisit the assumptions; they revisit the bill, and only when something looks wrong. But cost creep with no obvious anomaly behind it is usually a sign that the original model has quietly fallen out of step with how the workload runs now. This is exactly where a cloud cost review earns its place: not as a reaction to a spike, but as a way to test whether the assumptions behind the placement still hold.
Alternatives mature
Whenever a placement decision gets made, the options on the table are bounded by what exists and what is operationally viable at that moment. Services that were too immature, regions that had not opened yet, managed Kubernetes offerings that were not production-ready, sovereign cloud alternatives that did not exist at all: none of those could have factored into the original decision, but any of them might factor into a current one. Re-evaluating does not automatically mean migrating. It means checking whether the original comparison still holds: if the workload landed where it did because a particular service was the only realistic option, and something more capable or more cost-effective has matured since, that is worth knowing even if the right answer turns out to be leaving the workload exactly where it is.
Compliance and operating requirements shift
Some placement decisions expire for reasons that have nothing to do with cost or performance at all. Data residency requirements tighten, a customer segment in a new geography brings sector-specific obligations, regulatory frameworks change, internal governance standards evolve, or a funding round or acquisition introduces audit expectations that were not there before. A workload can be running perfectly well and still be sitting in the wrong place from a compliance standpoint, and the gap usually surfaces during due diligence, a customer review, or an audit. Not because the workload changed, but because the requirements did.
What an expired placement decision looks like in practice
These signals rarely announce themselves, which is part of why placement decisions go unreviewed for so long. The workload costs more than expected but no single line item explains the increase. Egress climbs steadily with no clear cause. The person who made the original call has moved on and nobody currently owns the reasoning behind it. A temporary environment that got stood up to hit a deadline quietly became permanent. Committed spend no longer lines up with how the workload is actually used.
The clearest tell is also the simplest: the team cannot say why the workload runs where it does, only that it does. When the logic behind a placement decision cannot be reconstructed, it is probably worth rebuilding. This connects to what we covered in the May post on cloud bill drift, where the bill starts showing patterns that no single change explains: patterns that are really the accumulated result of decisions nobody ever revisited. Placement is often part of what sits underneath them.
What re-running the comparison involves
A placement review does not have to begin life as a migration project. It can begin as a single question: is this decision still current?
A lightweight version follows a simple sequence:
- Identify workloads where the placement decision has not been examined in more than a year, or where recent shifts in usage, cost, or compliance suggest the original assumptions may have moved.
- Profile the workload as it runs today: actual compute usage, data movement, traffic distribution, and egress patterns.
- Compare that against what was assumed when the placement decision was first made.
- Check whether provider pricing has shifted, whether better alternatives now exist, and whether compliance and data residency requirements are still met.
- Decide whether to leave the workload as-is, optimise it in place, review the architecture more thoroughly, or open a deeper placement assessment.
The review is lightweight by design. The goal is to know whether the decision still holds, not to plan a migration.
The goal here was never to move everything: it is to know which decisions are still current and which have quietly drifted.
Two tools support this work at different layers. The Cloud Cost Comparator is useful for a fast first-pass check on whether provider pricing assumptions have moved since the original decision; it shows how a workload’s cost compares across providers today, which is a reasonable place to start when you are testing whether the financial basis for the placement still makes sense. UmbraFin operates a level deeper, surfacing what the workload actually costs now, how its usage has changed, who owns it, and whether the current setup is still financially coherent. Neither tool makes the architectural call: that stays with the team. What they do provide is a clearer starting point: real numbers, current usage, and fewer assumptions in the room.
Our FinOps consulting work often starts in exactly this place: not with a migration recommendation, but with a structured review of whether existing placement decisions still reflect how the infrastructure is actually used.
How often should teams re-evaluate placement?
There is no single right cadence. A fixed annual review suits some organisations; for others, the more useful frame is triggers. Some of those triggers are operational: a major shift in traffic patterns, entering a new customer geography, or a product change significant enough to alter how the workload behaves. Financially, the trigger might be a large commitment renewal, a sustained increase in unattributed cloud cost, or a quarterly review that surfaces unexpected patterns. On the compliance side, the review may come after a customer audit, a funding round, or a new regulatory obligation in a market you are expanding into.
The principle underneath all of them is that placement re-evaluation should feel more like a routine renewal than a root-cause investigation: a scheduled check made before the decision becomes a problem, not an inquiry triggered after it already has. For teams investing in platform engineering or CloudOps maturity, folding this into the architecture review cycle is a natural fit, and the question “is this placement decision still current?” sits comfortably alongside the ones already being asked about service health, ownership clarity, and cost attribution.
The decision was a snapshot. The workload kept moving.
Cloud infrastructure changes continuously; workload placement decisions do not change themselves. The distance between what a placement decision assumed and what the infrastructure is actually doing tends to widen slowly and invisibly until something forces a look. Because the bill is a lagging indicator, by the time cost creep is obvious, the drift has usually been building for months.
The first step still is not to migrate. It is to check whether the decision is still current. If your team is running workloads on assumptions made years ago, with no clear record of whether those assumptions still hold, that is the place to start.
TardiTech helps teams review cloud workload placement, cost signals, and operational assumptions so infrastructure decisions stay aligned with the business they support.
Get in touch to review whether your current setup still makes sense.