Big Bang?
In the “6 R’s” framework (or Amazon’s “7 R’s”), there’s a migration strategy labeled “Rehost” (or “Lift-and-Shift”). Cloud Service Providers advocate this approach, asserting that modernization and transformation are more straightforward in the cloud, and calling this effect "big-bang adoption". No wonder, for them it’s definitely a big-bang revenue growth.
While the approach is appealing, few companies can execute a simultaneous, overnight migration of all workloads:
- The potential blast radius of such migrations is immense, and so is the impact on business continuity.
- Once the cutover is over, it’s over. Reversing the process could be even more challenging.
- The number of teams involved in the project is extensive. Training them to operate in the Cloud, managing them during the cutover and subsequent troubleshooting is no small task.
- There’re technical limitations.
- There’re physical limitations! Like the speed of light or the speed of AWS Snowmobile.
As a result, a more tactical approach is often favored: slice applications one by one or in small chunks.
Slice-Lift-and-Shift?
Yet, upon closer inspection, pure lift-and-shift seems less feasible. Here’s why.
Our team is currently doing a complex migration project for our client, a big enterprise, moving numerous legacy applications in phases. Initially, the project was proclaimed a “lift-and-shift”. However, the initial stages of the project revealed that more exact definition for it would “kind-of-lift-and-shift”, later morphing into a “kind-of-kind-of-lift-and-shift”.
Here’s one example that illustrates our journey:
- All databases are hosted within a single massive DB cluster.
- We select an individual application’s database and start replicating it using AWS DMS to Amazon RDS. It gets a new connection endpoint.
- Wait a moment… the applications reference the databases using endpoints of the on-premises DB cluster and rely on their DNS names. But we migrate only one database. Hence, we can’t simply update all databases’ endpoints centrally with DNS!
- We must find respective connection strings across all applications in the portfolio and change them during cutover: these could be in configuration files, be hardcoded in software packages, or even stored in databases! Right, one database’s connection endpoints are stored in another database, we saw it!
- We create an automation to selectively update applications’ configurations to redirect them to the new database during the cutover.
- Rinse and repeat for other company-wide resources like file shares. The complexity rises in an
O^npattern.
Conclusions
This leads us to two significant conclusions.
The first is practical: Verify multiple times whether it’s a genuine lift-and-shift. Lift-and-shift migrations are primarily estimated based on effort per server (for instance, time taken to configure AWS MGN). From the scenario above, it’s clear that the bulk of the work is per application or a specific component of an application. The complexity (potentially O^n) can only be accurately estimated during a comprehensive, well-planned discovery phase.
The second is theoretical: My past experience draws a parallel with the CAP theorem from the theory of distributed systems. It was often misinterpreted the same way. At a micro-level, CAP operates flawlessly, that’s why it’s defined as a theorem. On a larger scale, we typically encounter a dynamic combination of CP and AP components and data flows. The same applies to migration strategies (“6 R’s” or “7 R’s”): on the micro-level, it might be “Rehost”, “Replatform”, or my favorite “Retire”, but on the macro level, it often results in an explosive mixture.