3 Approaches To A Better Cloud Migration

It’s time to rethink “Rehost,” “Replatform,” “Rearchitect.” Here’s how enterprise leaders can chart a more holistic approach to cloud migration.

With so many enterprises choosing digital transformation now, the question about cloud migration isn’t so much “why” as “how?” Enterprise leaders have plenty of options to choose from, though some are less efficient than others. When enterprises plan large-scale migrations of their applications to the cloud, they often devote countless hours to a top-down evaluation of their existing applications, then choose a discrete migration strategy like “rehost”, “replatform”, or “refactor” for each. This is a well-established industry practice in which the main question is how many Rs an enterprise requires for full migration. 

In practice, these “R” migration strategies aren’t really strategies at all—instead, they’re placeholders for all the questions an enterprise still needs to answer about each application. The policies and capabilities determined by an organization’s IT team are the biggest factors in determining the migration path. They’ll usually override a cloud architect’s top-down planning.

Also, very few applications fit completely into any one of these migration strategies across all of its layers. Looking at Google Cloud products as examples, the application’s database may get replatformed from self-hosted PostgreSQL to our managed Cloud SQL. The application layer may get rehosted as the same virtual machine (VM) on Compute Engine. The load balancer may get replaced with Google’s Cloud Load Balancing.

This is why organizations need a more holistic approach to migration, one that looks closely at an enterprise’s people and processes before focusing on the technology. In other words, you need to determine whether your cloud migration needs to be tactical, strategic, or transformational–or some combination. Then, armed with that insight, you can consider three fundamental approaches to migration:

1. Migration factory

The migration factory approach involves laterally copying or deploying VMs or containers in bulk. This approach works well if the applications are simple and similar enough and if the migration team can execute it without needing a lot of coordination from individual application teams. This scaled approach works well for initiatives that are infrastructure-led rather than application-led, especially wholesale data center exits. 

Where a migration factory approach doesn’t work as well is in a change management process (through internal policy or external regulation) in which each application must individually undergo a manual review. The work to review and control for the inevitable changes outweighs the time saved from the automated migration of the code and data itself. This is also true if your IT team needs to make changes to your CI/CD tool chain before deploying to the cloud. The additional change process further cuts the benefits of an as-is migration to the cloud. So before choosing a migration factory approach, an organization should take these scenarios into consideration. 

2. Greenfield software development

There’s another option at the other extreme of a migration factory approach. Here, an enterprise chooses not to migrate an existing application at all, but instead develops a new “greenfield” or “cloud-native” application that follows the textbook agile software development practices that iterates on and deploys an application over time in stages. Though this approach isn’t especially cloud-specific, the cloud’s managed and serverless services can accelerate the development of such a software solution.

Developing a successful migration strategy depends upon first understanding the reasons why your organization is adopting the cloud. Your approach will then follow.

In this model, an enterprise should treat a newly developed application as a product rather than a project, meaning its IT team won’t abandon its work after reaching the last milestone. Rather, the team remains dedicated to the application and continuously refines and expands its functionality for the entire life cycle of the application. This makes the greenfield approach fundamentally different from any kind of migration. For one thing, there are no predetermined schedules or architect-dictated requirements. Instead, there are sprints of incrementally feature-rich, usable software led by a small, cross-functional, and long-lived team. Also, all stakeholders should understand that it takes significantly more time to develop a new application than to migrate an existing one.

3. Modernization factory

Most enterprises perform modernization on an application-by-application basis.

Software modernization falls on a wide spectrum. There are many independent tactics and best practices to improve the scalability, availability, security, and durability of the application itself while also reducing the work needed to deploy and operate the application.

Picture the factory team as a layered microcosm of the business, transcending organizational hierarchies and binding members to the shared objective of landing an application in the cloud.

An organization can really understand its true total cost of ownership (TCO) savings through these incremental modernizations. That’s why improving an IT team’s DevOps capabilities fits so closely with cloud adoption. In the cloud, everything can be automated. For example, one effective modernization can be provisioning consistent project environments with the help of infrastructure as code (IaC). Some organizations see great scaling benefits from decoupling data from logic. Or to improve your security posture, removing shell access from all servers and allowing only for changes to be pushed through a CI/CD pipeline can be a game changer. Of the hundreds more examples of incremental software modernizations, none fit squarely into a migration strategy “R”.

A good cloud provider should inventory the common application layers (or “archetypes”) found in your enterprise’s current estate and help you choose a limited set of target cloud services, specific modernization tactics, and a degree of process automation. Then, once an application has landed in production in the cloud, you can consider additional modernization efforts above this baseline.

Who’s involved in a modernization factory? In a perfect world, a modernization team is a hybrid team composed of a small, cross-functional app team familiar with the individual application, and a “factory” team familiar with the set of target services and modernization tactics used across all applications. The app team enters and leaves the factory together with its application, while the factory team stays put and individually processes each application (and each app team).

Further, the factory team should include and hold accountable decision makers with the authority to block the successful completion of the migration. Picture the factory team as a layered microcosm of the business, transcending organizational hierarchies and binding members to the shared objective of landing an application in the cloud.

Finally, people can be trained on your new cloud operating model in the central forum of the modernization factory. This helps reduce or eliminate the number of IT employees trained on technologies they don’t immediately need, while ensuring that the app teams have the skills and methods to work successfully on their own after the migration concludes. Once the first modernization factory has proven its success, you can replicate it to process additional applications in parallel.

Picking the right migration approach

Which is the right approach for your applications? Developing a successful migration strategy depends upon first understanding the reasons why your organization is adopting the cloud. Your approach will then follow.

For example, looking at the Google Cloud Adoption Framework, let’s say you want to reduce cost with minimal, tactical changes to your applications. If so, we recommend the migration factory approach. If you want to maximize your software’s benefits with strategic improvements, we recommend the modernization factory or the greenfield software development approach. If you want to innovate with new transformational business problem-solving applications, we recommend the greenfield software development approach.

Once you’ve established the reasons why your organization is adopting the cloud and have agreed on your approach, everything else will begin to fall into place—including things that don’t begin with the letter “R”.

To learn more about migrating to Google Cloud, check out our data center migration site or sign up for a free cloud migration cost assessment.

Related: The 3 P’s of successful migration: How TELUS international put them into practice