4 remedies to avoid cloud app migration headaches

Once enterprises commit to running business-critical applications in the cloud, they rarely move to another provider. One big reason: they’re often locked into their chosen provider’s ecosystem. The cost of migrating is simply too high, says Sid Nag, VP of cloud services and technology at Gartner. “But if you do your planning exercise properly, you shouldn’t have to move your applications around,” he says.

Pablo Del Giudice, cloudops and cybersecurity studio partner at professional services firm Globant, adds that migration is possible if you position your organization correctly. And he and his team have done so successfully. “The key is to strategically adopt open platforms and frameworks, relegating the cloud provider to the role of an infrastructure layer,” he says. While this approach has a steeper learning curve, it yields more favorable results in the medium and long term, he adds. “The key is to bring in a platform-neutral software architect who can delineate business boundaries and create solutions that are less intertwined with a specific vendor.”

Jamie Holcombe, CIO at the US Patent and Trademark Office, has a slightly more nuanced take: he wants to keep his options open to move applications between cloud service providers, and conducts market research with all the major ones. But doing this requires planning ahead early on, before moving an application to the cloud the first time.

Minimize lock-in risks

You need to carefully weigh the tradeoffs when it comes to leveraging each vendor’s cloud-native services. “If you choose not to use a cloud provider’s native services in order to remain agnostic, you lose many of the ‘better, cheaper, faster’ business case metrics,” says Holcombe. “There’s a cost to being agnostic, just as there’s a cost to vendor lock-in.”

USPTO

Del Giudice breaks down cloud vendor lock-in into three forms. Platform lock-in occurs when you have a complete cloud foundation configuration (resource grouping, policies, RBAC, hybrid connectivity, monitoring, compliance, etc.) that make migration to another platform difficult due to the complexity of recreating all of that on a new platform.

Architectural lock-in is when the application relies on multiple managed services from the cloud provider. In this case you have to re-architect the application before you can migrate it.

And then there’s legal lock-in, where you’ve committed to an enterprise service agreement for a predetermined amount of time. “These commitments are difficult to terminate and make it difficult to execute a migration,” he says.

Sometimes vendor lock-in comes despite the CIO’s best efforts to avoid it. Mergers and acquisition activity often leaves organizations with multi-cloud architectures, says Nag, and while CIOs typically want to consolidate, the cost is often too high to justify. Most of the time, those CIOs decide to keep the multi-cloud model because they’re locked in. “You’re trapped, big time,” says Nag.

But organizations may have good reasons to migrate between IaaS providers, despite the obstacles, says Del Giudice. The most common are to obtain a better cost ratio between value and OPEX to take advantage of a competing cloud service provider’s aggressive discount, and to leverage a multi cloud architecture when your organization wants to improve reliability.

Plan ahead for potential future migrations

The desire, however, to move key applications between cloud providers, what Gartner calls “cloud repatriation,” is usually the result of bad planning, Nag says. He sees this with lift and shift deployments to the cloud, but also when organizations decide to use affordably-priced cloud-native middleware and development tools with the intent of moving the application back to an on-prem private cloud when completed.

Gartner

He recommends retaining the services of an MSP or systems integrator to do the planning and ensure you’re choosing the right applications to move to the cloud. “That’s important because once you’ve moved it, you’re agreeing to be locked into the platform.”

Financial services company USAA carefully chose which of its four cloud service providers host each of its workloads and regular business applications. “We aligned the cloud providers with the business or technical services they’re most proficient at,” says SVP and CTO Jeff Calusinski.

The institution’s multi-cloud strategy is grounded in what he calls its “open by design” principles. “We use open standards, where they exist, thereby reducing the potential for vendor lock-in,” he says, but admits some native services provide a compelling value proposition that must be weighed against the potential for lock-in.

Also, open design principles will only take you so far when it comes to lock-in, Nag says, because even when you’re using modern services, the implementation on each platform differs. For example, Amazon’s EC2 substrate does the same thing as Google’s GCP, but an application running on EC2 won’t run on GCP without a lot of expensive rework. And while Kubernetes is an industry standard, implementations of it, such as Azure Communication Services and Google Kubernetes Engine, don’t work identically.

“However, some abstraction layers have emerged between cloud providers and applications,” says Del Giudice, and those can simplify migrations even if native cloud provider services are used. “These services, such as pub/sub, service invocation, secrets management, state management, and so on, abstract the components of the application no matter the cloud provider.” So the bottom line, he says, is, “Your options remain open, but some activities will still need to be carried out in order to move from one cloud provider to another.”

Globant

Data requirements is another area that needs careful planning. “Moving an app across clouds is expensive because you also need to move the associated data, and data egress is a very costly exercise,” says Nag.

So plan for that in advance, adds Holcombe. “Don’t sign with a provider unless you have an agreement so you know how to get your data out and how to replicate those software services elsewhere,” he says.

But even if having an adequate ETL strategy can ensure you can move data between providers in a structured way and in a usable format, says Del Giudice, those plans are often non-existent. “Although cloud service providers emphasize the use of open platforms and data access protocols, which in theory are easy to use, network limitations and security to access these services are often overlooked,” he says.

When deciding which cloud-native services to use, sometimes organizations have no choice. Security is a good example. “If your security needs are high, generic cyber security might not be sufficient,” says Holcombe. The more specific your needs, the more rigid the service gets in terms of vendor lock-in. And companies with data-intensive operations face both storage and bandwidth issues, he says, adding that PaaS and IaaS providers use both as competitive differentiators. “If you’re trying to leverage high performance with both, that’s sticky,” he says.

Holcombe follows what he calls the “black spruce” approach to customizations that leverage native services. Just as the black spruce keeps its branches close to its trunk, USPTO keeps its customizations as “skinny” as possible, he says. Not only does that reduce lock-in, but it ensures the organization isn’t saddled with what he calls an overladen and costly versioning path.

Calusinski takes a similar approach. “Most PaaS options have a core capability and a set of ancillary capabilities,” he says. We limit the number of ancillary capabilities and focus on the core.”

USAA

The same goes for SaaS-based applications, Holcombe adds — a maxim his team followed after moving from Remedy to ServiceNow and Salesforce. “Don’t customize a lot, and be able to change out when you need to,” he says. “We’re not beholden to them and it’s been a good structural platform. But if it’s overladen with optimizations, you’re stuck.”

This time, however, Calusinski approaches things differently. “With SaaS platforms, we adopt as much of the platform as possible because as a business we don’t see enough differentiation [in] vendor capabilities, and the probability of change is low.”

Head off potential moving pains

It’s clear that migrating between cloud providers presents myriad challenges. These include compatibility issues, security concerns, the need for extensive application reconfiguration, and dealing with images based on old operating systems and outdated technology stacks that won’t seamlessly integrate into a new environment. Transferring large amounts of data can also lead to downtime and potential data loss, and ensuring consistent performance and scalability during the transition is crucial. “Managing these challenges requires meticulous planning, thorough testing, and a well-defined rollback strategy,” says Del Giudice.

Also, key failure points for PaaS migrations include not meeting cost or business expectations, underskilled resources, lack of standardization and security foundations, not leveraging cloud-native features, security and compliance concerns, and not adopting a cloud operating model.

Del Giudice recommends a six-step approach for any organization considering migrating between cloud providers. First, evaluate the subscription model to make sure it aligns with your ROI goals. Adopt a hybrid cloud approach. Use cloud-agnostic solutions wherever possible to keep your future migration options open. When using native cloud services, design your applications with abstraction layers. Invest in data migration planning, testing, and backup strategies to mitigate risks. And review and adjust licensing agreements as needed.

Weigh your options carefully

Always look at transition costs and data ownership when considering any cloud provider transition, says Calusinski.

And when it comes to striking a balance between using native cloud services that increase lock-in versus staying agnostic, there’s no right answer, says Holcombe, only an optimal one for your organization and its mission. The question, he says, is whether the cloud-based application aligns with your organization’s mission and offers the best value for accomplishing that over time. “If you have an overly complex cost infrastructure, you can’t change when the business model changes,” he says, adding to keep your options open as the USPTO has with a multi-cloud architecture by design. “My primary reason was to have competition between service providers,” he says.

When strategizing a cloud migration, it’s important to be mindful of pricing models, says Del Giudice. “Explore potential cost-saving plans, and factor in data transfer costs,” he says. “This approach is vital to prevent unexpected spikes in cloud operating expenses and ensure alignment with your budgetary constraints.” When executing a migration strategy, consider two other factors, he adds. First, what services, such as microservices or serverless, are available from the cloud service providers to facilitate migration? You’ll need to decide between using customized solutions or managed services from the cloud provider, which generate vendor lock-in risks. Second, the cloud provider may offer incentive programs for migrating applications, with discounts that can be substantial for large migrations.

By their nature, cloud migrations can be risky. But CIOs who plan ahead and are persistent enough to go through this process may see more cost-effective cloud services and pricing models, improved scalability and resource allocation, and enhanced performance and responsiveness. “Reduced vendor lock-in fosters greater agility and innovation,” says Del Giudice. “Ultimately, cloud migration can drive greater competitiveness, innovation and efficiency.”