What are the 6 R’s of Migration?

January 8, 2022 Vipul 0 Comments

The 6R’s of Migration briefly explained — What are these and how as a Business Owner one must know what kind of Migration do you need?

6R’s of Cloud Migration

Re-hosting — Lift and Shift Migration

Re-platforming — Lift-Tinker and shift Migration

Re-purchasing — Different product migration

Refactoring /Re-architecting

Retire

Retain

 

Different Types of Migration – 6R’s 
 
Businesses are taking to the cloud-oriented growth route to generate higher ROI at reduced costs, handle 
data sensitivity, for better security, faster response, scalability and overall improved efficiency. Cloud 
migrations are highly advantageous when schemed with the right type of solution at the right type of scale. 
Broadly, a business would subscribe to SaaS – Software as a Service, PaaS – Platform as a Service and IaaS 
– Infrastructure as a Service. Certain elements of all these three are blended to generate an ideal set-up 
while migrating to the new ecosystem. This transitional process is categorised into six different types 
called the 6 R’s of migration, namely, Repurchase, Rehost, Replatform, Refactor, Retire and Retain. These 
determine the application’s need for skill, time, resources and downtime. Not all applications of a 
business are treated the same way. Each one follows a distinct way of transition. Here is a quick note on 
different types of migration:  
 
Repurchasing – Drop and Shop 
Repurchasing Software as a Service has a classic example of switching an email service provider. You can 
transition from your on-premises setup to the cloud SaaS. This is a speedy manner of embracing 
minimalism in simplified procurement steps and least skill requirements. The sparkling new purchase 
requires little pruning of interlaced dependencies, license hiccups, CapEx-OpEx struggles and 
management skill mismatches. Here, scantier the baggage, easier the import. There are two common 
trends in Repurchase migration.  
Legacy to Cloud 
Here you would drop the legacy applications and adopt the cloud-based inventive apps. Ideally, such apps 
should be running in isolation to keep the process least invasive or the attached strings should be cut off 
prior to acquiring tenancy. Legacy to cloud repurchasing explores new dimensions of the technology with 
its cross software flavours.  
Trans Cloud 
Disruption in service, unsuitable features, higher feasibility on the other side and other favourable offers 
are some of the grounds to pull in for repurchasing. Office 365 to G-Suite is the most commonly cited 
example in SaaS switchovers. Automation assistance is not only available with such providers; it is the 
preferred manner in a multi-cloud software complex.  
Rehost – Lift and Shift 
Most Rehosting is done at the initial stages of cloud adoption or with disruption intolerant 
workloads. In both cases, the objective is to pack move and settle and then optimize the workloads as 
per the cloud landscape. It is low risk, speedy, tool-supported, flexible with system requirements and  
configuration adaptive. Rehost also has its flip side. Your new environment inherits all the good and bad, 
unchanged performance, unnecessary technical baggage and cross-service rigidity. Rehost is ideal for 
antiquated undocumented configurations or massive and severely complex models. At some point, this 
will need deep attention to cut down costs and optimise value. It is least painful in the pre-migration 
stages, cushions application fragility, maintains singularity of everything lifted and requires less skill set. 
However, Rehost cannot give you the full flavour of the cloud in the long run.  
Replatform – Lift, Tinker and Shift 
Replatforming is all about increasing application performance by shifting its architectural dependencies 
such as operating systems and databases. The tinkering job lies in handling external dependencies, cross-application integrations, load balancing, caching, condensing the code, etc. Heavily data inclined apps 
favour containerization, performance velocity, DevOps styled lifecycle and price justification of the 
resources applied. Replatforming evens down these values during the pre-migration phase. Here paring 
and patching skills are extremely essential for the anticipated disruption, thus, limits the role of 
automation. Once Replatformed to the cloud the app benefits in ROI, smooth performance, modern 
operational culture and architectural simplification. Some key involvements: 
Change certain components of the code but not all. 
  • You can Replatform a Rehosted application. 
  • Essentially alters legacy architecture for the cloud. 
  • Flex the application for ready-to-use SaaS features. 
  • Do not disturb the core. 
  • There is a lot of after-sale tinkering with the code.  
  • The post-migration effect is trimmed to a smooth pipeline of workload rather than ballooning up the resources. 
Refactor/ Rearchitecture/ Rebuild 
Refactor is a take all down and rebuild approach. Refactoring may involve deep surgical insertions into 
the code or complete makeover of at least half of the application, depending upon its current condition 
and entrepreneurial requirements. The main objective of stretching to such an extent is to acquire 
maximum advantages of the technology at reduced operational expenses. It saves the resource-intensive 
applications from chronic performance pains while distributing the ROI to a long-lasting steady rate. This 
the skilful and patient technique improves efficiency, caps piling expenses, provides controlled scaling, adds 
agility and proves highly beneficial for long term service-driven models. Some key features are: 
  • Invasive with the code 
  • Follows futuristic avenues 
  • Enhances mobility and multi-vendor usage 
  • Transfers much of the workload to automation in the long run 
  • Pushes the cost curve down with time 
  • Driven to serverless behaviour and containerization 
Retain/ Revisit 
One retains an application as is when it is critical, has a complex structure and cannot tolerate  
refactoring in the prevalent scenario. You save the job of revisiting for a later day. 
Retire 
Most of the wet blanket applications are retired to reduce the technical debt. These apps are at a 
crumbling stage and it is best to strategically retire them.  
Which one is for you? 
There is not one specific decisive criterion for migration. Each application has its own requirements and 
can employ an amalgamation of more than one type of migration. You need a detailed assessment of 
the current ecosystem before landing on a certain measure. Here is the most basic list of the 
assessment requirements: 
How long do you expect the app to run in the new environment? (Its lifespan in months) 
Is the workload prioritized and queued in the runbook? 
Is it meeting the compliance requirements in the new environment? 
How far can we employ automation tools? 
What features and facilities should we sift out or pull in?