Only Fools Rush In: How Incremental Cloud Repatriation Ensures Optimal Performance

Let me guess: you’re sick of unpredictable and / or sky-high public cloud bills. (There's no way cloud hosting should cost that much!)

Or else you’re tired of being beholden to a single provider for all your functionality.

Or maybe you’re at an inflection point in your growth: the cloud made sense five years ago but it doesn’t today.

And now you’re starting to hear rumblings from other people in your industry. You’re not alone. More and more of your peers are repatriating from the public cloud. It’s time. You want out.

Hang on.

I totally understand the FOMO, but rushing this move—and even rushing the decision of whether to leave the public cloud—can lead to disaster.

Instead, try this more methodical approach to cloud repatriation: first take the time to determine the best course of action for your organization, then make any changes incrementally.

Here’s how we approach these situations when they arise with our clients.

Start with the Problem, Not a Solution

Repatriation is a solution, but it may not be the right one for the nature of your cloud problems.

If you’re dealing with high bills, for example, maybe a different configuration or storage setup could deliver the cost savings you want. Ditto if you’re looking to boost performance. Maybe you could avoid the time and expense of repatriation entirely by allocating a fixed number of worker hours per week to infrastructure management. And so on.

Because while cloud repatriation is having a bit of a moment right now, it’s not one-size-fits-all. The first phase in any cloud repatriation project shouldn’t have anything to do with repatriation. Instead, it should involve inventorying all your workloads, architectures, dependencies, performance patterns, and costs and considering them within the larger business context.

In other words: first, you need a picture of where you are today.

Then, you can move to phase 2, where you score workloads using a workload typing matrix (critical, easy win, complex refit, etc.). Once you’ve done this work, you’re in a good place to determine whether repatriation makes sense to solve the problems you're currently facing.

Think of it this way: if you start getting utility bills that are much higher than you expected, your first solution wouldn’t be to move to a new house. It would be to see what's going on with your appliances: running toilet? Gas leak? Fridge on the fritz? Moving changes more than your utility bills; it changes your school district, your commute, your neighborhood amenities, etc.

Similarly, the problems you’re experiencing in the public cloud may or may not be best solved by repatriating. Doing the upfront assessment work is essential to the long-term viability of the business.

Related: Winning with Hybrid: How 5 Companies Optimized Performance with Hybrid Cloud Infrastructure

Design and Pilot to Avoid Downtime

Assuming you determine that repatriation makes sense, you’ll want to design a fit-for-purpose target architecture based on workload needs. That’s phase 3.

But it’s really important to avoid a “big bang” transition once you’ve got your destination architecture laid out. Big bangs introduce risk. They lead to unplanned downtime.

Instead, take an iterative approach. Run pilots of your new workload configurations. This lets you validate your models faster, learn what won’t work, and adapt. It lets you discover where your assumptions were wrong and identify performance bottlenecks before they’re scaled across your entire organization.

Above all, an iterative approach helps you avoid operational downtime.

Again, think of the house metaphor: if you’re going to all the trouble to move to a new location, it doesn’t make sense to solve just one problem (like cost of utilities). Why not also move to a better school district? A place with a nicer neighborhood pool? Better biking trails nearby? Better access to transit or nightlife or whatever else you value?

Cloud repatriation isn’t just an infrastructure move. It’s an opportunity to lay the groundwork for transformation. It’s rare to have this kind of opportunity in the life of a business, which is why it’s so important to make the transition in a considered, strategic way.

Prioritize Workloads based on Migration Complexity and Business Criticality

When you execute cloud repatriation incrementally, you can optimize in real time. What you learn in week one makes you more efficient in week two and beyond. This helps you stay on track, both budget- and time-wise, for the full repatriation.

So where do you start? We’ve found it’s helpful to prioritize workloads on two axes: migration effort / complexity and business importance (see diagram).

Workloads that fall in the bottom-left quadrant (simple and low importance) are good to migrate first. You’ll learn a couple things and you can get comfortable with the work of migration on these low-risk workloads.

Then consider creating pilots for those in the top left (simple but critical). Things here ~should~ go well, but if they don’t, the business suffers. A pilot lets you do a test run, then adapt as needed.

Workloads in the top right are both critical and complex. These require the most care to migrate.

Finally, workloads in the bottom-right quadrant, which are both complex and of low importance, should be assessed for necessity. That is: do you need to migrate them at all? Or can you sunset them?

This prioritization framework helps keep you focused on the big-picture business needs even as you dig into deep technical work.

Repatriation Is an Opportunity to Build the Groundwork of Transformation

Today, many organizations are considering cloud repatriation because the costs of operating in the public cloud have gotten unsustainable. But repatriation can achieve so much more than cost reduction.

If your organization is considering public cloud alternatives, keep the big picture in mind: high cloud bills are a symptom. The best solution depends on the underlying cause.

So before you rush into repatriating all your workloads, take the time to understand where you are today, identify where you’d like to be from a business perspective, and then create a plan for getting there incrementally—regardless of whether you decide to leave the public cloud.

When you take this methodical, gradual approach, you’ll save resources and end up with infrastructure that’s better suited to your long-term goals.