5 Criteria to Decide What Leaves the Public Cloud

In 2021, the board of a components manufacturer approved leaving its own datacenter and migrating the entire environment to the public cloud, with the promise of trading heavy hardware investment for a predictable monthly expense. Three years later, the bill had more than doubled without production having grown in the same proportion, and no executive could explain, line by line, what justified each step of the increase.

This pattern repeats with uncomfortable frequency in companies of every size and sector. Most migrated in batches, pushed by the end of a datacenter contract, the renewal of a server fleet or a continuity emergency, before any explicit economic criterion defined which workload belongs where. The decision was made by circumstance, and the price of that circumstance shows up years later, when moving anything has already become expensive.

This study proposes a matrix of five criteria, consumption profile, data gravity and volume, latency tolerance, regulatory requirements and the real cost of exit, to classify each workload among public cloud, private cloud, colocation (space in a third-party datacenter where the company keeps its own equipment) and on-premises infrastructure. The goal is not to crown a winning model, but to give the manager a defensible method before the board, the budget and the continuity plan.

The elasticity premium most companies pay without using

Public cloud pricing embeds an elasticity premium, the ability to expand or reduce capacity in minutes without buying equipment. That premium pays for itself in seasonal workloads, sales campaigns, accounting closes and test environments that exist for only a few weeks. It becomes silent waste when applied to an ERP (enterprise resource planning system) that varies less than 15% in load over the year, to a historical production database queried sporadically or to file servers whose growth is linear and known.

The second mechanism is physical and no contract solves it: latency, the delay between a command and its response. An MES (Manufacturing Execution System, which coordinates work orders, production reporting and quality on the shop floor) that talks to line controllers tolerates very little delay and becomes entirely dependent on the stability of the plant's link. When that link fluctuates for twenty minutes, the line does not slow down, it stops, and the loss is measured in orders without production reporting, batches without traceability and lost shifts. Measuring the cost per hour of downtime tends to change the conversation more than any infrastructure spreadsheet.

How to build the decision matrix

The starting point is an economic inventory of workloads, built with real consumption data from twelve to eighteen months. For each relevant system, record the variation between peak and trough, the associated data volume, latency sensitivity, the applicable regulatory requirements and the estimated cost of exit. Workloads whose peak exceeds three times the trough tend to justify the public cloud; flat workloads, with large volume and little variation, tend to cost less in private cloud or colocation, where the company buys dedicated, predictable capacity.

The second step is evaluation discipline. Require comparisons over a thirty-six-month window that include egress, licensing, network cost, migration effort and planned downtime, because monthly comparisons hide exactly what makes the decision expensive. Ask for the exit plan in writing before signing the entry, with an estimated timeline, data volume and export format. And treat the backup and disaster recovery strategy as part of the matrix, since where the data lives and where it comes back from need to be conscious, tested decisions.

Five questions every manager should ask

1. Which workloads in our operation have stable, predictable consumption and therefore pay dearly for an elasticity they rarely use?

Which workloads in our operation have stable, predictable consumption and therefore pay dearly for an elasticity they rarely use?

Few companies answer this with numbers, even though the information is available: the provider's own consumption dashboards show, workload by workload, the distance between peak and average. The exercise tends to reveal a predictable pattern, with management systems, historical databases and file servers operating at nearly constant utilization while being charged under a model designed for intense variation.

The consequence is budgetary and immediate. Over three-year horizons, flat workloads tend to cost far less on dedicated capacity than on elastic consumption, and that difference, applied to just the five largest workloads, frequently funds the repositioning project on its own. The manager who comes to the board with that list ranked by potential savings stops debating technical preference and starts debating capital allocation.

How much would it cost to pull our data out of where it is, considering egress fees, migration time and operational downtime?

That number has almost never been calculated, and its absence is what turns a reversible choice into permanent dependency. The calculation has four components: the egress fee on total volume, the engineering hours to redesign integrations, the period of parallel operation between environments, and the downtime window required for the final cutover.

Knowing that figure changes the company's position even when the decision is to stay put. A manager who knows what leaving would cost negotiates renewals with a concrete argument, sets a ceiling on volume growth in each platform, and prevents new workloads from inflating, through sheer inertia, the price of an eventual future move.

Which processes cannot tolerate the latency or link dependency that the public cloud imposes, and what happens to production when that link fluctuates?

The answer begins with an honest map of the processes that stop when the connection degrades. In industrial environments, this typically includes manufacturing execution, production data collection, vision systems, and integrated scales; in other sectors, it shows up in customer service, billing, and shipping, all of which depend on real-time response to keep the physical queue of people or goods from stalling.

The practical criterion is simple to state and uncomfortable to apply: whatever halts revenue generation when the network fluctuates must remain physically close to where the revenue is generated. A production line down for a few hours typically consumes, in lost margin, more than the annual savings achieved by centralizing that system in the public cloud, and that comparison of numbers belongs to the board, not to the infrastructure team.

Is our cloud bill reviewed with the discipline of a critical supply contract, with a named owner and a cost target per business unit?

Contracts for raw materials, energy, and logistics have an owner, a target, and periodic review, while the cloud bill tends to be treated as a utility bill, approved without analysis because no one feels authorized to question it. The first corrective move is to name an owner with an explicit mandate to reduce cost without degrading service, and a fixed review cycle with both financial and technical participation.

The second move is to adopt a cost metric per business unit, such as infrastructure cost per production order, per invoice issued, or per active customer. This metric separates legitimate growth from accumulated waste, because a bill that rises 22% while production rises 25% tells a very different story from a bill that rises by the same proportion with flat volume.

If the infrastructure budget had to drop 18% in the next cycle, could we say in less than a week which workloads to relocate and what the operational impact of each move would be?

The speed of the answer reveals whether a map exists or merely a history of accumulated decisions. Without a matrix, budget cuts become a linear reduction applied to every environment, a practice that penalizes equally what sustains revenue and what merely consumes resources, and that is usually reversed months later at the cost of an incident.

With the matrix in place, the manager has a sequence prioritized by savings and risk, in which each move already has a destination, a deadline, and an estimated impact. That responsiveness, more than the amount saved itself, is what turns the technology function into a trusted counterpart at the decision-making table, because it demonstrates command over the operational consequences of every financial choice.

Frequently asked questions

To put the positioning of your workloads to this test before the next budget cycle, talk to Zamak in a no-obligation Strategic IT Assessment.