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?