When it comes to migrating systems, data, and applications to the cloud, you can choose from many different approaches depending on your individual migration scenario. So how do you know which R approach to use? The four most popular approaches are Retire, Retain, Rehost, and Refactor, but there are other options too. In this article, we’ll discuss the different R options available to you when migrating to the cloud and give some examples of how these options have been applied in real-world scenarios.
Cloud Migration Basics
Cloud migration is the process of moving systems, data, and applications from an on-premises environment to a cloud environment. But, that’s not all there is to it! The cloud migration process can be broken down into a number of different R’s: retire, retain, rehost, refactor, revise, rebuild and replace. Considering these R’s will help you plan your own project more efficiently. Each R represents steps in your cloud migration process. Let’s discuss them one by one…
Retire – Putting Legacy Systems to Rest
Chances are you read the heading and instantly thought of that one system in your IT environment that you know needs to be in this category. If you’re thinking about migrating to a cloud service, it’s time to consider moving on from your old system. It might be running perfectly fine, but at some point, you will have to retire it. Your cloud migration project is the perfect opportunity to retire those legacy systems.
There are multiple considerations to assess prior to doing this, however. If the legacy system is still actively running a critical program for your business, it may not make sense to completely retire it. There are a few aspects that we’ll discuss briefly:
Old Server (Physical)
An old server is a relatively easy thing to retire. You would simply migrate the software residing on it to a new virtual server in the cloud.
Old Operating System
And old OS, along with old software which we’ll discuss next, is a bit more problematic. If you’re running an old Windows OS that is out of support with Microsoft, you won’t be able to spin up a virtual server in Azure with the same OS. So while retiring the OS itself is relatively simple, when it’s coupled with old software, it becomes a bit more difficult.
Old Software
If your business is using a software program that is several versions behind, or worse, is a software program that doesn’t even exist anymore, then you have some decisions to make in this regard. Are you willing to retire it completely? Or do you want to consider hiring someone who can keep it running in-house as a critical application?
There are multiple options for doing so, but none of them will be easy and all will cost money. If the software vendor has a new version of the program, consider discussing your situation with them. They may be willing to assist in the migration to ensure the old version functions in the new cloud environment, or they may be able to provide assistance with upgrading you to the latest supported version. Again, though, this will likely cost money.
Retain – Keeping It In-House
It sounds counterproductive to talk about not migrating a system into the cloud in an article about migrating to the cloud, but this R is one that should absolutely be a part of your cloud migration strategy. There are myriad reasons why retaining a system(s) in-house is a good idea.
One reason could be related to regulatory constraints. For instance, gaming regulations require certain casino systems must remain physically on-site at the casino in which the system is running. Another reason may be related to internal company policies regarding the storage of certain data. This is even more of a factor if your business deals with sensitive government data.
When determining which systems (if any) should be retained in-house, don’t forget to do a dependency mapping of what those systems connect to. Just because that system has to stay on-premises doesn’t mean that it doesn’t need to reach out to other systems for additional functionality, sharing data with other systems, etc.
Rehost – Same Stuff, Different Location
Rehosting is also known as a “lift and shift.” In rehosting, you simply move your system to another location. The process involves moving data out of existing systems—whether those are databases in an on-premises installation or virtual machines on your private cloud—and into new ones. Then it’s just a matter of managing everything on your own going forward.
If you’re trying to save money but don’t want to make significant changes, rehosting might be for you. It takes less time than refactoring and doesn’t require revising anything, so it can work well if you need to get up and running quickly.
But that quick turn-around doesn’t come without risk: You still have all your existing processes in place, along with all their corresponding procedures and systems. So although things will be better than they were before (because they have to be), they may not be improved by much.
Revise – Same Stuff, Different Platform
Revise (also known as re-platforming) is a bit more involved than any of the R’s we’ve reviewed so far. When revising, you’re modifying portions of the as-is architecture of the system you’re migrating. This might mean that you migrate your data layer from Oracle to Microsoft SQL or transition from IIS to Apache.
There are myriad reasons that you would elect to revise a system during your migration to the cloud. While performing your due diligence related to cloud migration, you may conclude that licensing costs of a certain component make it difficult to justify the move to the cloud.
You may also decide that a particular system would have better functionality on a different OS. All of these are valid reasons to choose to revise rather than simply rehost or retain during your cloud migration project.
Refactor – Update Your Code For the Cloud
This R is exclusive to solutions that are custom developed for your organization, whether in-house or via a software solution provider. Refactoring code to run efficiently and effectively in the cloud is a much greater effort, but the benefits could save your company a great deal of money over time.
Refactoring is especially important to consider for applications that have a web interface. Taking an application that is running on IIS and refactoring it to run as a “serverless” web app allows the application to be further optimized to be highly available and scalable.
When moving from Windows Server to Azure Web Apps, optimizing requires specific actions that would not otherwise be needed when simply moving from one environment to another. Moving away from hard-coded connections and towards more modularized architecture gives you more flexibility with how you can use Azure Web Apps in the future; being able to scale up/down as needed is just one example of how moving toward a microservices architecture can help make apps run faster and more efficiently.
Replace – Out With the Old, In With the New
As you continue planning your cloud strategy, you may conclude that some systems should be replaced altogether with a different solution. For example, you may determine that instead of moving your Quickbooks servers to the cloud, it would make more sense to migrate to Quickbooks Online.
When considering whether this R is the right move, there are a couple of things to keep in mind. First, if you have customizations in place on your existing system, it’s worth checking to see if they’re compatible with the solution you’re considering to replace it. Sometimes these customizations can be transferred over to save time and money; other times they simply can’t—and at that point, you might consider revising or rebuilding before proceeding with replacing.
Rebuild – Give Your System a Refresh
Lastly, you may determine that a system would benefit from a new set of servers on which to run. In this R, you aren’t upgrading any software or OS components; you’re simply spinning up new VMs for the program to run on and reinstalling the software on those VMs. This option can work well if your deployment is still relatively new.
The only significant downside of rebuilding your systems in-house is that you won’t reap all of the benefits provided by modern infrastructure tools like Docker or PaaS solutions.
The Most Important R: Research
The most important part of any cloud migration is research. Before making a single change to your existing systems, software, or infrastructure, make sure you’ve done everything you can to learn about how your cloud provider’s migration tools work. You might even want to contact other companies that have migrated using those same tools and ask for some advice or suggestions.
As long as you’re careful not to share any proprietary company information, doing so can help you gain valuable insights from people who have already been down a similar path—and even save you time and money along the way. Remember: This is an investment in yourself and your business. Making sure it pays off is a smart choice for everyone involved.
Migrations of any kind can be daunting, and there’s no getting around the fact that they require significant investments of time, money, and resources. Making sure your cloud migration is well planned cannot be understated. At Axeleos, we’re experts at all the Rs, and we can make your migration considerably less stressful by guiding you and your organization through each step. Contact us today and let us help you make your mark in the cloud!
cloud migration cloud migration