Public cloud is a really great place to put your application and database workloads. However, it’s not always clear how, exactly, that should happen. Some people talk about migrating, others about modernizing, a few mix everything together, and then there is a bunch of words that all start with the letter R.
In this post, based on my own experience, I’ll attempt to provide a clear differentiation between migration and modernization approaches, and how they map to a mysterious thing called the R-strategies. I will also introduce you to the third option called Midernization, or Moigration. Yeah, I know. The naming is a work-in-progress. Anyway, this is the option that no one recognizes, but almost everyone ends up doing it.
What are the R-strategies?
Simply put: R-strategies describe the cloud journey for your database, or an application. It’s worth noting, that sometimes that journey could be pretty short, or non-existent. Personally, I would (and often do) also challenge the idea of picking only one strategy for application. I’ll explain why, further below.
Like many popular things in IT, R-Strategies were given birth by consultants. In this case, analysts at Gartner. We originally had 5 R-strategies: Rehost, Refactor, Revise, Rebuild and Replace. Over the time, new R-strategies have been added, and some names have changed as well. Today, we’re already at 7! Rehost, Replatform, Refactor, Repurchase, Relocate, Retain, Retire.
The absolute majority of the work I do, is mostly centered around the options of Rehost and Replatforming. I have also invented a couple R-strategies myself, but I am saving those for the future. Furthermore, there’s no single list of R-strategies that is correct, so you can pick the one you like most. Here are the R-strategies defined by:
To their benefit, I admit, that the naming convention is very descriptive.
How do you define migration?
What is the difference between migration and modernization? One could assume, that by moving your database workload into a public cloud platform would be a modernizing it? The short, simple answer to that question is: No and maybe. If you move a VM, without any changes, from one data center to another, you are modernizing the infrastructure. But the database, it doesn’t get any more modern by moving it from one location to the next.
This, as-is migration, of a server is what I consider to be the purest example of migration. The operating system and any third-party software, including database services, would be absolutely identical to the on-premises environment. This operation, also called rehosting or lift-and-shift, is also often the quickest way to move any type of workload, thanks to available third-party solutions. Here’s a short list of services that can help with a server rehost:
Beyond Azure Site Recovery, these tools also typically include plenty of other functionality that can be useful. To me, everything, beyond moving the VMs through rehosting, is entering the territory of modernization.
What is modernization?
Modernization tends to have a much larger scale of changes that can fit into it. We can be talking about a small change in an application, going from IaaS to PaaS, changes of database schema, or it could be completely rewriting everything. With this, rather loose definition, modernization covers most of the R-strategies described previously.
Full modernization approach isn’t one that I typically see anyone pick, as their first option of going to cloud. Most organizations tend to first go to cloud through simpler migrations, and there’s also a good reason for doing so. If you’re new to the cloud, migrations allow you to develop maturity in how you operate there, as you move more and more workloads there. It’s also common that the full benefits of the cloud can only be realized, after you have had some exposure to it. So, having a short breather in the cloud can be beneficial, before considering modernization options.
What about the Mider… the Moig… The hybrid option?
Earlier, I was saying that I’d challenge the whole notion of using only a single R-strategy for any application. My main reason is, that for many migration cases, you must balance speed of delivery with the cost efficiency. As much as I appreciate Rehosting, due to minimal efforts required to move databases, and applications. It just doesn’t provide that much in the sense of optimizing your costs. Total cost of ownership (TCO), still matters to many companies starting their cloud journey.
And when it comes to TCO, do you know what costs a lot in the cloud? Databases do.
This is one of the main reasons, I almost always feel that the hybrid option is the best. So, you might ask. What does that hybrid option look like? The answer is again simple: You Rehost application servers, and you Replatform the databases. In this scenario, the Replatforming option is still a homogenous migration, with two specific goals.
- Move your databases to PaaS, to benefit from fully managed databases, and modern cloud infrastructure.
- Consolidate, where possible, to optimize the TCO for database services.
With these two, relatively simple additional goals in your Rehost plan, you’re going to get a much more satisfying outcome from your migration.
Thank you for reading! If you are interested in migrating or modernizing databases to the cloud, I do have another post coming up, describing some of the typical challenges we’ve seen.