Sometimes the Answer Is No
There are workloads that should stay where they are, and there are businesses that should not move at all. Saying so costs us work, and it is still the right advice, because a migration that makes a system slower and more expensive damages the case for every sensible project that follows it.
The cases below are the ones we see most. A load that never varies. Machinery on a factory floor. Latency that physics decides rather than engineering. Data that legally cannot leave a place. And software that would have to be rewritten to move, with no budget and no reason to rewrite it.
Every one of these is an argument for deciding system by system, with the actual numbers of your actual business, rather than adopting a direction and applying it to everything you own. None of them is an argument against cloud in general.
If you are getting advice that arrives at the same answer for every system in your estate, that is a finding about the advice.
A Steady, Predictable Load
Cloud pricing rewards variation. The whole economic argument rests on paying for what you use, and it only pays when what you use goes up and down. A system running at the same level every hour of every day collects none of that benefit and pays a premium for the option.
This is the common case in manufacturing, in logistics, and in any business whose systems serve a fixed number of staff doing a fixed job. The database supporting the production line does the same work on a Wednesday in March as on a Wednesday in September. There is no peak to absorb and no quiet period to give back.
Do the arithmetic on your own load before accepting anybody's summary. Compare the full cost of ownership over the life of the hardware, including the building, the power, the maintenance contract and the staff time, against the monthly rental of an equivalent that runs continuously, with a commitment discount applied and a realistic allowance for data leaving the platform. Some of these comparisons come out in favour of the cloud and some do not, and the honest ones vary by business.
Where it does come out against, the sensible answer is often not to keep the server in a cupboard either. Colocation gives you somebody else's building, power and cooling while you continue to own the hardware, and it is the option most often left out of these comparisons.
Machinery on a Plant Floor
Control systems that run machines are their own world and they follow different rules. The controller on a production line, the system driving a press, the software supervising a process: those need to keep working when the internet link goes down, and in most plants the internet link goes down at least once a year.
The vendor's supported configuration is usually the deciding factor. Industrial equipment often ships with a specific software version on a specific operating system, validated as a unit, sometimes with the warranty or a safety approval attached to that exact arrangement. Moving it invalidates the support arrangement, and the vendor will tell you so in writing if you ask.
There is also the question of who can help at three in the morning when a line is stopped. Local control means a local engineer can stand in front of the machine and work. A control loop that depends on a connection to a distant data centre adds a supplier and a network to the list of things that must be working before anybody can start.
What does move well is everything above the control layer. Collecting production data, reporting on it, planning, maintenance scheduling and analysis are all fine candidates. Keep the control local, send the data up, and be strict about the boundary between them.
Latency You Cannot Argue With
Distance costs time and no amount of engineering changes that. A round trip to a data centre in another part of the country takes what it takes, and if a process needs a response faster than the round trip, no configuration will save it.
Where this bites in practice is rarely the headline application. It is the chatty one. A system that makes many small calls in sequence multiplies the round trip by the number of calls, so an operation that felt instant on a local network becomes a visible pause when the two halves are separated. Older applications built when the network was a corridor rather than a country are especially prone to this.
It also bites where a person is waiting on a machine. A scanner in a warehouse, a terminal on a production line, a till in a shop. Those interactions happen constantly, and a delay that reads as tolerable in a test is exhausting when somebody performs it hundreds of times a shift.
The workable pattern is to keep the immediate interaction local and send the results onward. Local processing with a link to central systems handles the warehouse, the shop floor and the branch office well, and it is a legitimate architecture rather than a compromise.
Data That Genuinely Cannot Leave
Some restrictions are legal, coming from the rules of a sector or a country about where certain categories of data may be held and processed. Some are contractual, written into an agreement with a customer who wanted their information kept in a particular place. Both bind you, and the second sort is easier to overlook because nobody in the technology team ever read it.
The first thing to check is whether the restriction is actually about geography or about control. Where the rule names a country, the major platforms have regions in India and in most large markets, and the requirement is often satisfiable with careful configuration. That includes making sure backups, replicas, logs and support access all respect the same boundary, which is the part people miss.
Where the restriction is about control rather than location, it is harder. A requirement that no third party may hold the data at all, or that the encryption keys never sit in a system your provider operates, points towards keeping it yourself. Read the actual wording rather than the summary somebody gave you in a meeting.
And check the surrounding services, because that is where these arrangements break. The main system might sit in the right region while the monitoring platform, the ticketing tool, the analytics service and the support team all sit somewhere else and see the same data.
The System That Would Have to Be Rewritten
Some software cannot move without being rebuilt. It depends on hardware that does not exist in a cloud environment, or on a licence tied to a physical machine, or on an operating system version that no platform will run. Occasionally the vendor is out of business and nobody has the source.
Anything can be rewritten given enough time and money. Whether the return justifies that cost is the real question, and for a stable system that does its job and is not going to change, the honest answer is often no.
Sensible things to do instead. Get it onto supported hardware in a proper facility. Make sure the backups work and have been restored. Isolate it on the network so its old operating system is not a way into everything else. Write down what it does and who understands it. Then leave it alone and revisit when something changes.
The trap is spending three years half moving it. An application partly migrated, with pieces on both sides and a link holding them together, costs more than either end state and is worse than both.
Where Cloud Clearly Wins, Because Fair Is Fair
Anything with a variable load. Seasonal retail, events, campaigns, month end processing, anything that is idle most of the time and very busy occasionally. That is the case the pricing model was built for, and the saving is real rather than theoretical.
Anything new. When you are building something and do not yet know how big it needs to be, renting capacity beats buying a guess. The ability to be wrong cheaply is worth more in the first year than any discount.
Disaster recovery, even for businesses that keep everything else in their own building. Paying for a standby environment that sits nearly idle until it is needed is exactly the shape of thing that rented capacity does well and owned hardware does badly.
And any business too small to run its own infrastructure properly. If your server lives in a cupboard, backs itself up to a disk beside it, and is administered by whoever is most confident, moving to a managed platform improves your position on every measure that matters, cost included.
How to Decide Without a Slide Deck
List your systems, and for each one write down the load pattern, the latency requirement, any legal or contractual restriction on where the data sits, the vendor's supported deployment, and what it would take to move. Five columns, one page, most of it filled in by people who already know the answers.
Then work out the real cost of each option for the systems where it is genuinely close, over the life of the hardware you would otherwise buy. Include the things that never make it onto the comparison: the building, the power, the maintenance, the person who patches it, the replacement cycle, and on the other side the data transfer and the support plan.
Expect a mixed answer, because a mixed answer is what an honest assessment usually produces. Some systems move, some stay, and a few move partly. That is a fine outcome as long as each decision has a reason attached to it and a date to revisit.
Anyone who tells you the answer before looking at your load, your latency and your contracts is selling something. Sometimes what they are selling is also what you need. You should still make them show their working.
