GCP – Rethinking ‘rehost, replatform, rearchitect’: Cloud migration for the real world
When helping customers plan large-scale migrations of applications to the cloud, we here on the Professional Services team sometimes observe them pouring countless hours into the top-down evaluation of their application estate and categorizing them into discrete migration strategies like “rehost”, “replatform”, “refactor” and so on. It’s a well1 established2 industry3 practice4 in which the only open point for debate, it seems, is whether there are 5, 6, 7 or 8 distinct “R’s”.
In practice, the popular “R” migration strategies aren’t really strategies at all—they’re placeholders for all the things you don’t yet know about your applications. We find that an IT organization’s policies and capabilities do more to determine the migration path than anything else and ultimately override any architect’s prior top-down planning.
What’s more, almost no application falls squarely into any one of the migration strategies across all of its layers. The database might get replatformed from self-hosted PostgreSQL to managed Cloud SQL while the application layer might get rehosted as the same VM on Compute Engine, while the load balancer might get replaced with Google’s Global Load Balancer.
What most organizations usually need is a more holistic approach to migration. That’s why when our Professional Services teams engage with customers, we pay little attention to these semantics. In this early planning stage we’re more interested in people and processes before we focus on the technology. First, we may recommend you consider the Google Cloud Adoption Framework, and determine whether your cloud migration needs to be tactical, strategic or transformational. Then, armed with that insight, it’s time to consider three fundamental migration approaches:
Migration factory
The migration factory approach, in which we laterally copy or deploy virtual machines or containers in bulk, works well if the applications are simple and similar enough and if the team handling the migration can execute it autonomously without needing to coordinate much with individual application teams. This scaled approach is well suited for initiatives that are infrastructure-led rather than application-led, in particular wholesale data center exits, and can be expedited with solutions like Google Cloud VMware Engine or specialized tools like Migrate for Compute Engine or our Database Migration Service.
By the same token, the migration factory approach doesn’t lend itself well to a change management process (through internal policy or external regulation) in which each application must individually undergo a manual review. The effort of reviewing and controlling for the inevitable changes outweighs the time saved from the automated migration of the code and data itself. The same is true if you need to make material changes to your CI/CD tool chain before you can deploy to your cloud environment. And once you factor in the change process, the commercial case for an as-is migration to the cloud becomes less compelling.
In summary, there are some specific scenarios in which the migration factory approach is the best option, but there are many other scenarios that don’t meet the criteria.
Greenfield software development
At the other extreme of a migration factory approach, there’s the option not to migrate an existing application at all, but rather to develop a new “greenfield” or “cloud-native” application instead. This approach essentially follows textbook agile software development practices. While there is nothing specific to the cloud about this approach, the cloud’s managed and serverless services lend themselves particularly well to accelerating the development of such a software solution.
A newly developed application must be treated as a product and not as a project, meaning the team does not abandon its work after the last milestone has been reached. Rather, it remains dedicated to the application and continuously refines and expands its functionality in perpetuity (or until the application is deprecated). In this regard, the approach is fundamentally different from any kind of migration. There are no predetermined schedules and the architect does not unilaterally dictate requirements—there are only sprints of incrementally feature rich, usable software. The team tasked with developing the application must be small, cross-functional and long-lived. It also takes considerably more time to develop a new application than to migrate an existing one.
Modernization factory
The majority of migrations that we see our customers engage in involve some degree of modernization on an application by application basis.
Software modernization falls on a wide spectrum, involving a multitude of independent tactics and best practices to improve the scalability, availability, security and durability of the application itself while also reducing the amount of toil in deploying and operating the application.
It’s through these incremental modernizations that customers usually realize their true TCO savings—and it’s also the reason why improving their DevOps capabilities naturally goes hand in hand with cloud adoption. In the cloud, because everything is an API, everything can be automated.
For example, provisioning consistent project environments with the help of infrastructure as code can constitute a noteworthy modernization. Decoupling state from stateless logic can have great scaling benefits. Removing shell access from all servers and allowing only for changes to be pushed through a CI/CD pipeline can be a game changer for your security posture. There are a hundred more examples of incremental software modernizations and none of them squarely fit into a migration strategy “R”.
When we work with our customers to land their applications with some degree of modernization on Google Cloud we take stock of the common application layers (or “archetypes”) found in their current estate and mutually agree on a limited set of target cloud services, a set of modernization tactics and a degree of process automation through CI/CD and infrastructure as code. Any additional modernization effort above this baseline should be postponed until after the application has landed in production in the cloud.
A modernization factory requires a hybrid team construct, composed of a small cross-functional app team that is familiar with the individual application plus a “factory” team that is familiar with the portfolio of target services and modernization tactics to be employed across all applications. While the app team enters and leaves the factory together with its application, the factory team stays in place and processes one application (and one app team) at a time.
Crucially, the factory team must include representation from—and hold accountable—all decision makers who have the authority to block the successful completion of the migration. Think of the factory team as a matrixed microcosm of the business that transcends organizational hierarchies and binds everyone to a single shared objective: to successfully land an application in the cloud.
Last but not least, the modernization factory provides a central forum in which to train people on the new cloud operating model. This helps mitigate against prematurely training swathes of IT employees on technologies for which they don’t have an immediate need, while also ensuring that the app teams have the skills and ways of working to be successful on their own after the migration concludes.
Once the first migration factory has a proven track record of success, additional modernization factories can be spun up to migrate more applications in parallel.
Recommendation
So, which approach should you take for your applications? To develop a real migration strategy, first answer why your organization is adopting the cloud. How you approach it follows from that.
For example, harkening back to the Google Cloud Adoption Framework, if your objective is to reduce cost with minimal change to your applications (i.e., tactical) then we recommend taking the migration factory approach. If your objective is to maximize the benefits you get from your software (i.e., strategic) then we recommend taking the modernization factory or the greenfield software development approach. If your objective is to innovate with net new applications that solve new business problems (i.e., transformational) then we recommend taking the greenfield software development approach.
After you’ve established why your organization wants to adopt cloud and have agreed on how you would like to approach it, 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 center or sign up for a free cloud migration cost assessment.
1. Gartner’s 5 R’s
2. AWS’s 6 R’s
3. Citrix’s 7 R’s
4. Infosys’ 8 R’s
Read More for the details.
