Liberty Center One CTO Steve Searles recently joined the ROCC Pod to talk about cloud repatriation, AI, cybersecurity, and the infrastructure decisions businesses are facing as technology continues to change. 

One of the most important issues he raised was a cloud strategy assumption many businesses made years ago: the cloud was treated as a “fit-all for everything.” 

But workloads change. Businesses grow. Performance requirements evolve. Infrastructure decisions that made sense when you moved to the cloud may not make sense for every workload today. 

Your cloud can be working exactly as designed and still not be the right environment for every workload. 

That does not mean abandoning AWS, Microsoft Azure, Google Cloud, or public cloud. Steve’s point is more practical: different workloads have different requirements, and where you put them matters. 

Support matters. Latency matters. Flexibility matters. Physical location can even matter when milliseconds affect how quickly a business-critical application can process and return data. 

That is why more organizations are taking a second look at workload placement as part of their cloud strategy. 

Here are five signs it may be time to take a second look at yours. 

What is cloud repatriation? Cloud repatriation is the process of moving selected workloads, applications, or data from a public cloud to another infrastructure environment when changing technical or business requirements make another environment a better fit. Cloud repatriation does not require abandoning public cloud completely and can be part of a multi-cloud approach. 

Key Takeaways 

• Cloud repatriation does not mean leaving public cloud entirely. You can move selected workloads while keeping others where they are. 

• Support and flexibility matter alongside infrastructure. Your cloud environment needs to fit both the workload and the team managing it. 

• Physical distance can affect latency. Location matters more for applications requiring rapid processing and response. 

• Different workloads can belong in different environments. The goal is to put each workload where it can operate most effectively. 

5 Signs It’s Time to Rethink Your Cloud Strategy 

Your cloud does not have to be failing before you reconsider it. In fact, some of the most important warning signs have less to do with whether the infrastructure is technically “working” and more to do with whether it still works for your business. 

1. Getting the Support You Need Has Become Too Complicated 

When a critical workload has a problem, how many companies does your team have to call before someone takes ownership? 

If the answer is not obvious, your support model may be working against you. 

Searles identifies support as one of the major reasons businesses reconsider their cloud environments. 

“Customer service is what matters,” he says. For businesses relying on critical infrastructure, that means being able to reach someone who understands the environment when help is needed. 

The problem becomes more pronounced when one provider supplies the infrastructure, another company manages it, and your internal IT team handles everything else. 

As Searles explains in the podcast, that can leave you “dealing with three vendors all at once.” 

If resolving a cloud issue requires figuring out who is responsible before anyone can address the problem, it may be time to reconsider the support model surrounding that workload. 

2. Your Critical Workloads Are Sensitive to Latency 

How much does a delay matter to your business? 

For email, a few extra seconds may make little practical difference. For a production environment making time-sensitive decisions, the answer can be very different. 

Searles uses an automotive production line to illustrate the problem. “Imagine a camera capturing an image of a component for quality assurance. That image needs to travel to infrastructure for analysis and return quickly enough to help determine whether production continues.” 

Now add distance. 

As the physical distance between where the action occurs and where the data is processed increases, latency increases. That is not a cloud-provider problem. As Searles points out, “it is a matter of physics.” 

Liberty Center One’s experience supporting infrastructure for automotive and manufacturing organizations provides a practical perspective on why the physical location of cloud infrastructure can still matter. 

Searles goes deeper into this example in the podcast, including when location matters and when it really doesn’t. 

3. You’re Forcing Different Workloads Into the Same Infrastructure Model 

Are you treating fundamentally different workloads as though they all need the same thing? 

An ERP system is not email. A manufacturing application is not a collaboration platform. A latency-sensitive application can have very different requirements from a workload that runs perfectly well in a hyperscale public cloud. 

Yet organizations can fall into the habit of making a single infrastructure decision and applying it broadly. 

Searles identifies support and flexibility as important reasons businesses reconsider where particular workloads are hosted. 

Instead of asking: “Should we be in the cloud?” Ask: “What does this workload actually require, and is its current environment still providing it?” 

That small change in the question can lead to a very different cloud strategy. 

4. No One Clearly Owns the Problem 

If something breaks, can your team immediately answer one question: Who owns the problem? 

Multiple technology partners are not inherently a problem. Unclear accountability is. 

• Who owns the infrastructure? 

• Who owns troubleshooting? 

• Who is accountable for resolution? 

If those answers involve several companies, multiple support queues, or uncertainty about where one provider’s responsibility ends and another begins, the operational burden can become significant. 

This is different from simply wanting better customer service. It is about ownership. 

When your infrastructure supports critical business operations, there should be no confusion about who is responsible when something needs attention. 

5. You’re Assuming Every Workload Belongs in the Same Cloud 

If you are evaluating every workload by the same cloud criteria, you may be asking the wrong question. 

Cloud repatriation is sometimes presented as a choice between staying with hyperscale public cloud or leaving it. 

Some workloads make sense with AWS, Microsoft Azure, or Google Cloud. Others may benefit from a different environment because of latency, flexibility, support, or other operational requirements.