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?

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, resour
Here is a quick note on different types of migration:

1. 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. Thesparkling new purchase requires little pruning of interlaced dependencies, license hiccups, CapEx-OpEx struggles and management skill mismatches. Here, scantier the baggage, easier theimport. 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 flavors.

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 assitance is not only available with such providers; it is the preferred manner in a multi-cloud software complex.

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

3. 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 rchitectural simplification.

Some key involvements:

• 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

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

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