Most infrastructure decisions begin life as perfectly sensible answers to the question being asked at the time.
Then the workload changes. The organisation changes. Pricing changes. Someone adds an integration that becomes indispensable, the original architect leaves, and a temporary workaround celebrates its fifth birthday.
None of this means the original decision was wrong. It does mean that “we decided this years ago” is a reason to review the decision, not a reason to preserve it in amber.
Cloud and on-premises are still too often discussed as rival camps. Pick a side, defend the flag and try not to mention the invoices. In practice, most IT leaders I speak to are dealing with a much less theatrical problem: they need each workload to run somewhere that makes operational and financial sense, and they need to be able to explain why.
That sounds straightforward. It rarely is.
Linux Is Portable. Your Workload May Have Other Ideas.
Linux gives us a useful degree of choice. It runs almost anywhere, from a small physical server to the largest public clouds, with rather fewer objections than most of us would make if asked to move house that often.
That portability is real, but it can be misleading. Moving an operating system is not the same as moving a working service.
A production workload has accumulated storage, network rules, identity services, certificates, monitoring, backup processes, deployment automation, security controls and support arrangements. It may also depend on a cloud-native database, object store or messaging service that has quietly become part of the architecture. The Linux component may be ready to travel. Everything attached to it may be less enthusiastic.
This is why a credible placement review starts with the whole service rather than the server. What does it depend on? Who understands it? How is it recovered? What has to change if it moves? And which parts of the current environment are genuinely valuable rather than merely familiar?
The last question is often the most interesting.
A Large Cloud Bill Is Evidence, Not a Diagnosis
Cost is frequently what gets an infrastructure review onto the agenda. Fair enough. A bill that rises faster than the value being delivered needs attention.
But a large cloud bill does not automatically mean the workload belongs on premises. It might mean the architecture is wasteful, resources are oversized, old services have never been removed or nobody has been given enough ownership to challenge consumption. Repatriating all of that may simply relocate the inefficiency and add the cost of a migration project for good measure.
The comparison also needs to be transparent in both directions. Public cloud costs are visible because somebody sends you a detailed invoice. The full cost of on-premises infrastructure has a habit of being spread across hardware, facilities, power, software, support, staff time, spare capacity and several budgets that do not regularly meet for lunch.
Neither model becomes cheaper through selective arithmetic.
A useful review asks what it costs to run the service properly in each credible environment. That includes the people and operational disciplines required, not just the technology sitting underneath it.
Predictability Is Valuable, Although Never Very Exciting
Cloud is particularly useful where demand changes quickly, services need to be provisioned rapidly or managed capabilities remove work that the organisation genuinely does not want to own.
Other workloads are steady, long-lived and hungry. They consume broadly predictable resources, operate within known boundaries and do not need to scale from twelve users to twelve million before breakfast. For those workloads, dedicated infrastructure may offer a better financial or operational fit.
Predictability is not glamorous, but infrastructure is allowed to be boring. In fact, for important systems, boring can be an excellent quality.
The mistake is to apply either conclusion to the entire estate. A development environment, a compute-intensive research workload and a customer-facing application may need very different things. Treating them as one placement decision is neat on a diagram and rather less neat in production.
Repatriation Is Not Cloud in Reverse
The word “declouding” makes the process sound pleasantly simple, as if workloads can be cleared away after a spell of bad weather. Cloud repatriation is more involved.
Bringing a workload back requires a destination architecture, capacity planning, operational ownership, security controls, resilience, backup and recovery. Skills that were partly provided by the cloud platform may need to exist inside the organisation or through a specialist partner. Hardware lead times and growth allowances return to the conversation. So does the question of who gets called when something behaves oddly at two in the morning.
There can be a strong case for repatriation. Greater control, predictable demand, data-location requirements, performance needs or a poor whole-life cost in the current environment may all justify it. But it is a new design decision, not an undo button.
Multi-Cloud Can Reduce One Dependency by Creating Several Smaller Ones
Multi-cloud also deserves a little healthy scepticism.
There are sound reasons to use more than one provider. Different platforms have different strengths. Regulatory or customer requirements may influence placement. A particular dependency may need to be reduced, or an acquisition may leave the organisation with more than one cloud whether it wanted them or not.
But using several providers does not automatically make a workload portable or resilient. It may instead create several sets of identity controls, cost models, skills, monitoring tools and operational processes. It might be worth it. But it should be a deliberate decision to go down this road.
If a multi-cloud strategy depends on every workload running identically everywhere, test that assumption early. Marketing diagrams are admirably tolerant of latency, data gravity and different platform services. Applications tend to be fussier.
The Operating and Support Model Belongs in the Architecture Discussion
Placement decisions are often described in terms of cost, performance, resilience and security. One more factor deserves equal billing: can the organisation operate the resulting environment well?
An elegant target architecture is of limited use if it depends on skills the team does not have, processes nobody owns or documentation that will be written during the traditional quiet period after go-live. The technically possible option is not always the operationally sensible one.
For a Linux estate, I would want to understand where knowledge sits, how consistent the systems are, what is automated, how patching and upgrades are handled, whether restores are tested and who owns the gaps between platforms and teams. Those details reveal more about the viability of a move than a simple comparison of compute prices.
They also help distinguish a placement problem from a management problem. Sometimes the workload is in the wrong environment. Sometimes it is simply being run badly in the right one. Moving it will not cure that.
A Better Place to Start
Before deciding that a workload should move, I would ask five things:
- What has changed since its current home was chosen?
- Which parts of the service are genuinely tied to that environment?
- What would the complete operating cost look like elsewhere?
- Can the proposed destination meet the recovery, security and performance requirements in practice?
- Who will own and operate it after the migration team has packed away the project plan?
There may be a clear answer. There may be several defensible answers with different compromises. Occasionally, the review confirms that the workload is already in the right place and simply needs some housekeeping. There is no prize for moving infrastructure unnecessarily.
There is considerable value in knowing that the decision still stands up.
If you are reviewing cloud costs, considering repatriation or trying to make sense of a mixed Linux estate, we are happy to talk it through. You do not need to arrive with a preferred answer or translate the problem into Linux terminology first. Tell us what has changed and what is causing concern; we can take the conversation as far into the technical detail as it needs to go.
Explore Cloud Migration, Repatriation and Multi-Cloud Services
