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
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.
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
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.
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
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?