Scribd
Upload
18 views2 pages

6 Types of Migrations

Uploaded by

Balamurugan Subramaniyan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
18 views2 pages

6 Types of Migrations

Uploaded by

Balamurugan Subramaniyan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

1. REHOST – Also known as “lift-and-shift.

”
In a large legacy migration scenario where the
organization is looking to implement its migration and
scale quickly to meet a business case, we find that
the majority of applications are rehosted.
Most rehosting can be automated with tools such as
AWS Server Migration Service (SMS), although some
customers prefer to do this manually as they learn
how to apply their legacy systems to the new cloud
platform.
It has also become evident that applications are
easier to optimize/re-architect once they are already
running in the cloud. Partly because your organization
will have developed better skills to do so, and partly
because the hard part — migrating the application,
data, and traffic — has already been accomplished.
2. REPLATFORM – Sometimes referred to as
“lift-tinker-and-shift.”
This entails making a few cloud optimizations in order
to achieve some tangible benefit, without changing
the core architecture of the application. For example,
you may be looking to reduce the amount of time you
spend managing database instances, so you move
to a database-as-a-service offering like Amazon
Relational Database Service (Amazon RDS).
3. REPURCHASE – Replacing your current
environment, casually referred to as “drop and shop.”
This is a decision to move to a newer version or
different solution, and likely means your organization
is willing to change the existing licensing model it
has been using. For workloads that can easily be
upgraded to newer versions, this strategy might allow
a feature set upgrade and smoother implementation.
11
4. REFACTOR / RE-ARCHITECT –
Changing the way the application is architected and
developed, usually done by employing cloud-native
features.
Typically, this is driven by a strong business need
to add features, scale, or improve performance
that would otherwise be difficult to achieve in the
application’s existing environment.
If your organization is looking to boost agility or
improve business continuity by moving to a serviceoriented
architecture (SOA) this strategy may be
worth pursuing—even though it is often the most
expensive solution.
5. RETIRE – Decommission or archive unneeded
portions of your IT portfolio.
Identifying IT assets that are no longer useful and can
be turned off will help boost your business case, and
direct your team’s attention toward maintaining the
resources that are widely used.
6. RETAIN – Do nothing, for now—revisit.
Organizations retain portions of their IT portfolio
because there are some that they are not ready to
migrate and feel more comfortable keeping them
on-premises, or they are not ready to migrate an
application that was recently upgraded and then
make changes to it again.
You should only migrate what makes sense for the
business, but the more your portfolio moves to the
cloud, the fewer reasons you will have to retain.

You might also like