6 Rs of migration

Transition strategies commonly seen in cloud migration projects



Definition of Refactor

  1. Writing a new version of the existing application, with a new architecture and design in mind. In a refactor, you gain by removing any unnecessary components, leveraging newer application technologies in the cloud and generally providing an improved user experience and performance.

A refactor migration is the most transformational transition type for our custom applications.

The selection of this transition type is driven by a strong near-term business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.

This pattern tends to involve the largest upfront investment, and is generally reserved for applications that (a) are a core-competency for the organization (b) no suitable SaaS solution exists and (c) offer the greatest business value, either through savings or other agility metrics.



Definition of Replatform

  1. Changing the underlying infrastructure technology that an application runs in today, as we move it to the cloud. Some application changes may be required, but not a complete refactor. Examples are: changing operating systems, moving from one architecture to another (AIX to x86), changing database versions or engines and containerizing applications.

Small modifications to our application to allow it to be deployed to cloud-native services via pipelines. This transition type generally allows us to take advantage of the most compelling cloud computing tenets (elasticity, security, cost-efficiency), with the least amount of effort.

Specifically, here we will attempt to replatform our databases from proprietary engines such as Oracle, to cloud-provider services which remove the operational burdens and are generally priced on a consumption basis. Additionally, we will attempt to replatform our application code to one or more cloud-native services, such as serverless functions and queuing systems, as well as containers.



Definition of Repurchase

  1. Replacing the current system by purchasing a SaaS solution that meets the needs and requirements of the current application. Note: This can result in a data-migration and transformation project of its own.

Sometimes this involves moving to a new product to replace an existing commercial off-the-shelf (COTS) or custom application, but most commonly this transition type is applied to COTS applications that now have SaaS offerings from the vendor. We choose this transition type whenever possible, as it almost always offers the simplest path to doing less “IT” while still retaining the service.

The canonical example here is MS Exchange -> Office 365, removing the operational burden of email infrastructure while arguably providing more than the legacy on-premise solution. Other relevant examples include moving CRM solutions to Microsoft Dynamics or Salesforce.com, and an HR system to Workday.



Definition of Rehost

  1. Sometimes called ‘lift-and-shift’, this involves the replication of virtual machines from their current location into a cloud environment.

A rehost transition type is generally employed as a last resort when a compelling event like a datacenter closure, hardware lease, or supportability period end is driving the migration.

The reason the rehost is often a last resort, is that support for applications in a replatform scenario has increased greatly in the last 2 years, leaving little reason to attempt this no-value transition.

Having said that, should rehost be employed, it can be automated with data replication and/or disaster recovery tools.



Definition of Retain

  1. Keeping the application as-is, in its current environment.

When we select retain as our transition type, we are doing so because an application is becoming end of life during our migration project at which point it will be retired or “die on the vine”.

Alternatively, this application may be deemed as out of scope, to be revisited for migration later in a subsequent project.



Definition of Retire

  1. Getting rid of an application.

The application is no longer delivering value, or being used. Decommission it immediately and recoup the savings.

Note: This is often used in application rationalization scenarios.

Get in Touch

We'd love to solve your migration pain.

Contact Us