Multicloud is having a crisis. Gartner predicts that over 50% of multicloud or cross-cloud efforts won’t deliver on expected benefits by 2029, with poor interoperability and fragmentation serving as key culprits.

While these numbers don’t speak to cloud migration directly, from my own experience as an IT leader, plus from my field research in developing FluidCloud, I can tell you that multicloud disappointment and cloud migrations go hand in hand.

What causes all that frustration? To a large extent, you can blame the tools. Infrastructure migration systems propose to deliver end-to-end automation, from initial replication through ongoing governance. In reality, these applications leave huge gaps in the migration process. Instead of multicloud freedom, IT teams face a cascade of unanticipated work, expense, and friction.

The good news: To address the migration challenges, my colleagues and I have developed a new approach to cloud infrastructure portability, cloud cloning. In two articles here, I will [[outline the shortcomings of previous approaches]] and [[explain how cloud cloning solves the above problems]]. The goal is to help firms capture the multicloud promise at last.

To start, below I dive into what’s missing from the three main categories of legacy cloud infrastructure migration offerings: cloud-native tools, infrastructure as code, and governance products. In the companion article, I describe how cloud cloning answers these legacy issues with a wholly new approach.

Cloud-native migration tools: A one-way street

If you’re migrating to a hyperscaler, the cloud providers’ own migration offerings—such as Azure Migrate, AWS Migration Services, and Google Cloud Migrate—feel like obvious choices. Built specifically for the cloud you’re moving to, these solutions can provide excellent automation for provisioning and migration with templates, snapshots, managed services and more.

The problem is design for a specific service can also mean design for one service. These solutions are provided to facilitate migration to the clouds that provide them – ideally (from the cloud provider’s viewpoint) for a long time. They’re not designed to encourage free portability across clouds.

This design-for-stickiness includes guiding customers toward native services (such as AWS CloudFormation, Azure Cosmos DB, or GCP Firebase Authentication) that won’t run correctly elsewhere without significant rewrites to the applications built on them. The solutions also often encourage lock-in pricing—for instance, by recommending a particular infrastructure along with a three-year plan commitment to maximize savings.

To be clear, it’s arguably unfair to ask cloud providers to operate differently. After all, we can’t expect providers to offer capabilities and pricing designed to help customers move off to their competitors. But it’s also true that the customer’s goal is to work with whatever cloud is right for them, at any given time. This puts the customer and cloud provider at cross-purposes when it comes to cloud-agnostic computing—which is why, when it comes to migrations, it’s best for customers to seek out unaligned options.

Infrastructure as code tools: Automate only part of the way

With automated, version-controlled foundations to build from, infrastructure as code (IaC) solutions like Terraform and OpenTofu have earned their spot as crucial cloud migration assets. Their huge popularity is no surprise (Terraform’s AWS provider alone has topped 5.5 billion downloads).

The problem is that these solutions tend to translate infrastructure into broad terms, leaving critical small details to teams to work out on their own. This oversight can be especially problematic in areas like security policy, network load balancing, and firewall models and configurations, where small differences between one cloud and the next can be both make-or-break for migration success and extremely difficult to find. Even after using IaC, teams still must spend exorbitant amounts of time poring through plans, state files, and live resources to catch and correct these subtleties that fall through the cracks.

None of this is meant to undermine the value that infrastructure as code solutions provide. In fact, in the companion article I describe how Terraform is central to FluidCloud’s cloud cloning process. IaC is a powerful instrument in the migration arsenal; it’s just not reliable by itself to ensure that migrations succeed and resources behave as they should.

Governance tools: Built to find problems, not fix them

It’s unquestionable that observability and finops platforms like Datadog, New Relic, and Kubecost can be crucial in surfacing underutilized resources, performance bottlenecks, and budget overruns. The problem is that while they’re often excellent at spotting problems, most don’t guide teams to take the critical next step toward solving problems and optimizing cloud setups.

• As their name implies, observability tools are designed to observe and report on issues, not to automate solutions. For instance, they might detect high CPU usage or spot failing requests, but they won’t then launch new servers, add containers, or adjust configurations to fix the problem. It’s on customer teams to do that work.
• Finops applications, meanwhile, might alert users that a region they’re using is particularly expensive. It won’t follow up with automation to help port infrastructure over to a cheaper area, or show cost comparisons to help teams find alternative clouds to rebuild current infrastructure at a lower cost.

Governance offerings are often excellent at flagging critical issues, which is unquestionably helpful. But without automation to follow up, they’re only raising problems without offering solutions. That isn’t helpful enough.

Across these examples and classes of applications, the underlying issue is the same. The market is full of products that, in theory, turn the complex cloud migration process into something predictable and efficient. The reality is that IT teams are left with extensive “last mile work” of translating and implementing source infrastructure in the target cloud’s architecture and dependencies.

IT teams deserve a better solution. Cloud cloning solves the problems I’ve laid out above. I explain how it does so in this article.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.