The 6 R’s of Cloud Migration
When you’re at the start of your cloud migration process, it’s always helpful to review the basics and know that you’ve got a good plan ahead. That’s why we’ve compiled a list of the six R’s of cloud migration.
Use them as a framework when you sit down for a discussion with your stakeholders — you’ll be better able to create a solid foundation for your changes.
As we begin, let’s recall that every cloud migration is going to be unique, and that these “6 R” strategies are not meant to be definitive or mutually exclusive. They also definitely are not the only way you can define your situation, but what we’re after is a framework for talking points, a blueprint for starting discussions and guidelines.
This version of the six R’s of cloud migration was taken from our recent webinar Journey to the Cloud: Top Strategies for Migration Success.
Rehost
Rehosting is commonly referred to as lift and shift. Right now, lift and shift is generally as it sounds — lifting servers or applications from their current hosting environment, which is generally going to be on-prem — and shifting them to infrastructure in the public cloud and rehosting. The lift-and-shift strategy is a very common strategy for organizations starting out on their migration journey.
There are significant benefits to running servers on the scalable, pay-as-you-go infrastructure of a cloud platform. It’s a relatively low-resistance migration strategy, and it’s a great strategy for working backward from a fixed constraint or a hard deadline. For example, if we need to get something off our current infrastructure by November because we know it’s not going to be able to deal with the input of our October sales, in practice the application server will be exported using a third-party export tool like VMware’s vCenter. You can use any sort of virtualization service and create an image and that’s exported and imported into a cloud compute service. We can containerize things. The process is relatively simple; it doesn’t require a lot of technology, and it doesn’t require a lot of expertise.
Replatform
The second option is replatforming, and this is where we modify “lift and shift.” Replatforming involves making some optimizations to the application during the migration stage, so that does require some programming input and expertise. For example, you might end up moving from your own relational database system to a turnkey managed RDS on a cloud provider — same underlying tech, different business model with cloud resiliency auto-added.
Repurchase
This is sometimes referred to as “drop and shop,” as it refers to a decision to move to another product. This may mean ending existing licensing and repurposing services on new platforms or services. Examples you may have are a CRM system or an industry-specific application not designed to run on cloud infrastructures. This is often not necessarily a custom application, but it can be one that doesn’t have modern application code, or it could be a situation where it’s not possible to transport the code from one provider to another. The “repurpose” strategy is often applied when using a proprietary database platform or a proprietary product and moving to something else.
Refactor
The fourth R is refactoring, which is basically re-architecting. This is usually driven by a strong desire to improve a service or application. Drivers for this might be difficulty making improvements to the current environment, or a requirement to improve availability and reliability of the application immediately for an anticipated burst of traffic and activity.
The solution is to refactor this application so that it can handle that type of burst activity. If it’s not a mission-critical service, then it may be possible to re-architect during the migration stage (i.e., refactoring is feasible during the first stage of a migration if you do not have a time constraint). Otherwise, it’s most likely better to complete this in a later phase of the project. This is just something to keep in mind, because one of the key problems with refactoring is that it’s going to take a little bit of time and expertise.
Retain
The fifth strategy is to retain. You may want to retain portions of your IT portfolio because there are some applications that you’re not ready to migrate and you feel more comfortable keeping them on-premises, or you may need to do so for compliance reasons. With this use case, it may make sense to retain aspects of your IT services in the current environment and implement a hybrid or part migration strategy. This approach makes sense if you’re currently regulated or you have constitution rules that require you to store or run some aspects of your services or business applications on-premises or within specific regions.
Retire
This brings us to our last strategy, which is to retire services. This strategy involves identifying assets and services that can be turned off so the business can focus on services that are widely used and of immediate value. This is a really interesting approach because you can start to look at your applications quite differently — you start to see these big changes as opportunities and you ponder refactoring one thing, rehosting another. It’s a very exciting starting point, but like some of the other strategies, it will involve technical teams to make sure things are done correctly.
Scale responsibly, my friends
Change doesn’t happen overnight, and a cloud migration is no different. In our recent webinar, Journey to the Cloud: Top Strategies for Migration Success, we discussed just that.
Watch it on demand!
Feature Photo Credit @scobleizer (https://www.flickr.com/photos/scobleizer/4870003098)
