Getting cloud migration right is crucial to your applications' continued and improved functioning. Backups in the cloud can help you maintain a data center in a remote location, ensuring business continuity even in the event of a disaster. Many teams want to shift their workloads to the cloud, but few have a robust strategy in place. Going in blind for cloud adoption is one of the biggest mistakes you can make. Instead, tailoring your approach to your business and application use cases will help you successfully migrate to the cloud.
You can migrate to cloud service providers like Microsoft Azure, Salesforce, or AWS, each of which provides you with computing resources for cloud migration.
If your on-premises infrastructure is no longer serving your needs, but moving your applications to the cloud seems like a daunting task, read on to understand the various migration options at your disposal and how you can make the most use of them.
What are the 6 Rs?
In 2010, Gartner published the 5 Rs - rehost, refactor, revise, rebuild, and replace - that users should think about when migrating to a cloud platform. Amazon Web Services (AWS cloud) added their own spin to this perspective, establishing the following 6 Rs that usually form a team’s cloud migration strategy:
Rehost
The quickest way to migrate to the cloud, rehosting, or lift and shift involves making a copy of your existing on-premises services to the cloud. This is only feasible if no changes are to be made to the application before you export it, which means that it is already compatible with the cloud environment. This saves both time and effort. The lack of complexity suggests that your team does not need to possess a specialized skill set to execute the transfer. For the same reason, you can also automate the process without worrying about any complications. Because the application is not modified, if something goes wrong once it has been moved to the cloud, your team will not have much trouble identifying the cause of the problem.
This method, however, comes with certain limitations. While it is compatible with and functioning adequately in the cloud computing environment, your application is not optimized for it. As a result, there is no guarantee that your application can derive benefits from the cloud’s various features within its virtual machine. The lack of optimization and scalability of the cloud service also makes it difficult to scale the application in the future. The simplicity of rehosting, then, can sometimes be a bane rather than a boon. Instead of treating it as an end in itself, teams are known to use a lift and shift approach to get the actual migration process out of the way before reengineering their applications in the cloud.
Replatform
Going a step further, replatforming makes changes to your application’s configurations and environment while leaving the application itself untouched. By modifying certain aspects, your software can operate within the cloud infrastructure. It’s worth noting that the application does not automatically become cloud-native, despite displaying a few such characteristics. It is only better adapted to the cloud and can benefit from its offerings. This is a significant advantage, especially when considering the cost and effort invested, which remains negligible. The level of complexity and risk, too, is at a minimum.
This approach is useful when you are not willing or able to modify your application but would still like to take advantage of the cloud environment. It is important to be on your guard and only implement changes that you have accounted for in your plan. Often, teams get carried away when replatforming and exceed the initial time and resource limits.
Rearchitect
When rehosting or replatforming do not suffice, teams usually rearchitect their applications before exporting them to the cloud. In some business cases, the on-premises architecture is not useful in the slightest. Business motivations such as a need for improved performance or additional features that cannot be realized in the current environment usually inform the business need to rearchitect the software.
Rearchitecting your application helps modernize underperforming services or make them fully compatible with the cloud environment. To achieve this, you must break down the application into its various components and rebuild it such that its functionality is improved and it is optimized for the cloud. Since this act of optimization is deliberate and carefully planned, successfully-completed rearchitecture is guaranteed to help your application use the cloud.
For teams thinking long-term, rearchitecture is a particularly appealing option. Not only does it future-proof your services, but it is also more cost-effective in the long run despite high initial costs. The advantages of having devoted a great deal of time, money, and effort also become apparent with time. Your applications are more efficient, both in and of themselves and owing to their compatibility with the cloud environment.
On the other hand, it may be difficult to justify the upfront cost and skill-related demand imposed on your team. Rewriting the application brings with it considerable risk. To soften the blow, you can adopt a piecemeal approach to rearchitecture instead of pushing it all in one go.
Repurchase
If the process of actually migrating your applications continues to seem daunting, repurchasing offers an alternative to exporting part of your software. This approach calls for replacing your existing on-premises services with SaaS solutions, often via a subscription model. This takes off some of the pressure and responsibility of migrating the entirety of your architecture.
SaaS solutions are most commonly implemented in the case of business functions that do not have a tangible impact on your profits. Their offerings can be limited in the sense that it would not be possible to purchase a specialized service that your team had built in-house to meet certain needs specific to your software. However, they can leverage the cloud’s benefits and are often cheaper than rearchitecting your services. As an external product, they are already cloud-native and regularly upgraded. These cloud-native features have significant advantages, save for the fact that there is a lack of autonomy by their being general services that any interested company can purchase.
Retain
You might not be ready to migrate some parts of your application to the cloud. In this case, you can retain these services on-premises while exporting others to the cloud. Depending on your goals and the services themselves, you can choose to revisit these parts in the future when the conditions have changed.
Common reasons for choosing to retain services include:
These services are not ready to be deployed to the cloud or function perfectly on-premises.
The specialized nature of certain services means that there exists no equivalent that is compatible with the cloud at that point in time.
You have poor cloud connectivity for the time being and may only be able to move a few services to the cloud.
The services were changed or upgraded only recently, and it does not make sense to do this again through migration.
Certain regulations around the data being used require these services to be located on-premises.
Although these services are currently in use by your application, they will be retired soon. It makes little sense to relocate them for a limited period.
If you choose to retain some services and export others, you are working with a hybrid cloud architecture. This adds a layer of complexity and can be difficult but not impossible to manage. By retaining some services, you may not fully leverage the cloud benefits available to you. That being said, a hybrid architecture can also be a temporary solution while the ultimate goal remains to move the entirety of the architecture to the cloud. You can choose between private and public cloud services based on your user base and the sensitivity of your data.
All in all, the retain strategy offers an important reminder that just because you can, doesn’t mean you should. Sometimes it simply makes more sense to leave your services as-is.
Retire
If you are currently running services that you no longer actively use and it is unlikely that they will be of value in the future, it is best to archive or retire them. This frees up space for new services and your code is decluttered. Continuing to keep these onboard only contributes to the wastage of resources and hikes up expenses. A service to retire is often something that was recently rearchitected or replaced by another service, or whose offering is no longer contributing anything meaningful to the larger software architecture. Be cautious when retiring services, as some of your other existing applications may depend on them.
Retiring any legacy applications early in the application migration process is beneficial for a number of reasons. Not only does it reduce the effort required to maintain your overall architecture, but your team can also focus on migrating the services that have been cleared for export. Doing so also allows you time to reverse your decision if you decide that the service is, in fact, relevant to your core architecture. Even if you stick to your original plan, you may want to keep the data used by these services and will need to comply with certain regulations to be able to do so.
Successfully implementing the 6 Rs
Knowing which of the aforementioned strategies you will employ is only half the battle. To get the best out of these approaches, we recommend incorporating the following steps into your cloud migration process.
Establish a Baseline
To even begin implementing any of the strategies mentioned, you need to have a baseline i.e., an understanding of what is currently in your IT infrastructure. Before you even think about a cloud migration strategy, make sure you have complete visibility into everything that is running in your on-prem infrastructure. If you attempt a cloud migration without this level of visibility, you will likely miss something or copy services that are no longer running. To avoid wasting time and energy, do an audit of your existing environment and make sure that you have a thorough understanding of it.
If you are working on a big project, for example, you are not going to simply go in and start coding. First, you need to write a tech spec document and outline the approach, the current situation, and the objectives. You need to ensure that all relevant actors see and are aligned on these matters. When you eventually start developing the software, you will know exactly where you stand. Investing time upfront may feel laborious, but it will make the migration process easier.
Here are some questions you should dedicate time answering at this stage:
What do we have?
Where and how is it running? Is it still on our legacy system, or is it already up on the new cloud environment?
What purpose does it serve?
Who is accountable for it?
What dependencies does it have?
Cataloging
Using a service catalog at the inception of a cloud migration seems counterintuitive, especially because much of the information might get outdated. The bright side is that it forces you to understand the current status of your infrastructure by breaking it down into a few meaningful parts. This means that you acquire knowledge about the different services that hold your application together, where these are at present, and whether they are active.
Determine ownership
Subsequently, you assign team members or teams to each of the assets in your catalog. If something goes wrong as part of the cloud migration process, you should know which team is responsible since they are in charge of preparing those cloud services for the new cloud strategy.
Once you have assigned owners to these assets, you can dig deeper into the purpose and other relevant information about these parts of the cloud infrastructure. These questions can all go to the owners, forcing them to reflect not only on these queries but their understanding of the assets that they are responsible for. Sometimes, this will lead to the knowledge that the asset in question falls under the purview of a different team. Do this exercise early in the process so that you can get any reflections and conversations surrounding ownership out of the way. This will flag incorrect ownership and give you time to match assets with the appropriate owners.
Capture metadata
Once you have a catalog and the relevant owners in place, you are in a better position to fill out information for each asset. Where and if it runs, whether it is multi-cluster or multi-region, and if it has a failover are examples of metadata you should be capturing for each service at this stage. Any additional metadata you deem important for your cloud migration strategy must also be recorded.
Execute the migration
Equipped with these details, you can set the migration process into motion. Take stock of all the components in your infrastructure that need to be moved and brainstorm how you will do it. If in your catalog most services are multi-region, it might make sense to have multi-region automation for the cloud migration. The aim is to understand trends and focus areas so that you can make the migration process smoother and easier.
At this stage, you can contemplate which of the 6 Rs are relevant to your motivations and services. Anything that has to be retired, for instance, must be taken care of before you start the migration process. Owners must have full confidence in the services they are migrating. If anything is to break, it would be better for it to break in your on-premises operating system, where your team knows how to troubleshoot. Similarly, make decisions regarding what, if anything, needs to be retained. You can then move on to choosing the appropriate strategy for the assets that are to be exported to the cloud.
Continuous monitoring
After migrating your services to the cloud, continue to ask your cloud service providers and service owners about the state of these services. Ensure that the relevant information is up to date and valid. Cloud migration can sometimes last a few years, in which case owners might change. This must also be documented. Continue asking the same questions about the services to cloud providers and capture the metadata periodically. Having this information will help you understand if the migration has been successful.
Take the first step
In addition to the six strategies themselves, knowing how to build a coherent plan is essential to migrating your on-premise applications to the cloud successfully. Cataloging, ownership, and accountability contribute to the structure of strategy. Cortex’s service catalog is designed to provide you with all the information you need to bring visibility to your cloud migration process. Having a foolproof baseline will help you make informed decisions regarding the future of your services. Book a demo with us today.
