"Move everything to the cloud" has become a broken record in board meetings: someone heard "everyone already did it," ordered the whole project at once, and a year later the cloud bill costs more than the server it replaced. The opposite answer is just as common: the company freezes, decides not to touch anything, and the most important system keeps running on a machine nobody left knows how to fix.
Both answers share the same mistake: treating the decision as a single choice for the whole company. A 2023 survey of Brazilian companies by Cetic.br already showed that is not how the decision plays out in practice: 53% of companies paid for cloud email, a simple service to switch; only 33% paid for cloud processing capacity, and just 24% for a platform to host their own systems in development. That gap is not delay — it is selection. Companies already decide, system by system, what is worth moving.
The people deciding are not only whoever signs the IT contract. It is the owner or director who approves the investment, and the person responsible for IT who has to live with the choice afterward. For both, the right question is never "cloud or not" — it is "does this specific system gain, lose, or only work once it is reworked before moving".
What changes from system to system
The same Cetic.br survey shows the difference by industry: among information and communication companies, 57% already paid for cloud processing capacity in 2023; in accommodation and food services, the share was 23%, and in manufacturing, 27%. It is not that one industry "understands technology better" — the systems each one runs have different profiles of dependency, update cycle, and how critical they are to daily operations.
A system gains from the cloud when usage varies through the month (a year-end sales spike, payroll processed once a period), when people in different locations need to reach the same system, or when the vendor already ships the cloud version as the default — email and office tools are the simplest example. It also helps when the cloud provider has a data center in Brazil: Microsoft's Azure keeps a region in São Paulo, which brings the system physically closer to users here.
A system works better in-house when it talks in real time to a local piece of equipment — a production machine, a scale, a turnstile —, when the connection to the cloud provider is slow or unstable, or when the monthly cost of running it outside beats the cost of keeping it in-house. That math has to be calculated, not assumed.
There is a third group, the easiest to overlook: systems that only move once they are updated or rewritten. Microsoft's own Azure migration guidance treats a compatibility assessment — system version, database version, the libraries in use — as a step that comes before any decision to move, and recommends changing a system's underlying structure only when there is a clear business reason, because that kind of change takes significant development and testing effort. A system the vendor itself has stopped updating is not a candidate to "move as-is": it needs a fix-it step first.
Why deciding everything at once does not work
The common approach is to pick a side and apply it to everything. On one side, the company hires a full migration because it heard it cuts costs — and finds out months later that the system that used to run with no variable cost in the server room now generates a bill that climbs with usage, with nobody having worked out beforehand what that would cost at the company's real volume.
On the other side, the company that resists any change keeps an old system running on a physical machine that gets harder to replace every year, repeating "the vendor said it doesn't run in the cloud" — without checking whether that line, heard a few years back, is still true today.
Both postures share the same blind spot: neither one did the system-by-system assessment. The question "what changes for the company" — in access time, in dependence on one specific person, in the ability to recover after an outage — never got asked for each system individually.
The scale of getting this wrong shows up in broader infrastructure numbers. In the Uptime Institute's most recent look at data center outages, published in May 2026, 57% of companies hit by an outage reported losses above US$100,000, and one in five (20%) reported losses above US$1 million. The figure is not cloud-specific — it is about the cost of a poorly sized infrastructure decision, whether it sits inside or outside the company.
What has to be in place
An inventory of what the company has, system by system. Without knowing what exists — version, vendor, who depends on whom —, any decision to move is a guess. It is the first step before any cloud proposal.
A technical criterion per system, not only a financial one. Latency to the user, dependence on local physical equipment, whether the vendor supports a cloud version — each answer changes the outcome for that specific system.
Migration in stages, starting with the simplest. Test and internal-use systems first; the system that runs the core operation only once the process has already been validated on something less critical.
A monthly cost estimate before moving, not after. What a system costs today, sitting in a room, has to be compared with what it will cost running by usage — without that, the savings the cloud promises is just a guess.
A plan for what does not move yet. A system with no vendor-supported cloud version goes on a list with a deadline — update, replace, or rewrite — instead of being forgotten until it breaks.
A single person accountable for the whole decision. Without someone owning the outcome, each system gets decided in isolation by whoever bought that project at the time, and nobody revisits the choice later.
This is how Skills IT works: with an inventory of every system before any proposal, a technical criterion per workload, and a monthly cost estimate presented before any change is made.
What decision-by-system actually gains you
The gain is not "save money with the cloud" nor "keep everything as is" — both are possible side effects, not the goal. The real gain is that each system sits where it best supports the business: what needs access from anywhere gets access from anywhere; what needs an immediate response stays close to where it is used; and what needs an overhaul gets a scheduled one, instead of turning into a problem discovered the day it breaks.
The financial effect shows up in predictability: without moving out of hype or freezing out of fear, the monthly cost of each system is a known number, calculated in advance — not a surprise afterward. The operational effect shows up when something breaks: when the inventory already exists, the team knows exactly what to check instead of rebuilding the map from scratch under pressure.
There is also a gain for whoever approves the budget: a cloud proposal that arrives without this assessment is only half a proposal. The director who asks "show me system by system, what changes and what it costs" is asking for exactly what should have been done before any contract was signed. That is why, at Skills IT, the first deliverable of a cloud project is that assessment — not the price quote.
A starting checklist
- List every system that supports the operation, with vendor and version. Without this list, the next decision has no foundation.
- Mark, next to each one, whether it depends on another system or on local physical equipment. That is what decides whether it can move alone or only as part of a group.
- Ask the vendor, in writing, whether a supported cloud version exists — and since when. "It doesn't run in the cloud," heard three years ago, might no longer be true.
- Calculate the projected monthly cost of running each system outside the company, before deciding. Compare it with the cost of keeping it in-house, including maintaining the current equipment.
- Start the migration with a low-risk system, not the most important one. What you learn from the first system lowers the cost and risk of the next ones.
- Define what stays out for now — and for how long. A system that does not move today needs a review date, not a "never speak of it again."
