Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 22

Migration Plan:

. There are many ways of migrating your applications, data and workload to cloud, the easiest and least
expensive of which is the lift-and-shift method.
Rehosting, also known as lift-and-shift migration, is often considered to be
the simplest approach to cloud migration. A rehost simply means taking the
entire application from its old infrastructure and moving it to the Cloud, all
without making changes or adjustments to the code. This is also why
rehosting is known as lift-and-shift: you lift the code out of an environment
and shift it to another.
Lift-and-shift is a strategy used to move applications from one platform to another, without redesigning the
entire app. In other words, you take your workload as it is and run it on cloud-based services.
The complexity of the workload and its compute, storage and network requirements are the major factors to be
considered before deciding whether to lift-and-shift the application or to re-architecture it. The factors should
be mapped from the available resources in the on-premise infrastructure to what the cloud-based service can
provide.
Benefits of Lift-and-Shift Strategy for Cloud Migration

Pre-Migration steps :

1) Python is installed on the machine – Python 2 (2.4 or above) or Python 3 (3.0 or above).

Verify that you have at least 2 GB of free disk on the root directory (/) of your Source machine for the
installation. To check the available disk space on the root directory, run the following command: df -h /
2) Free disk space on the /tmp directory – for the duration of the installation process only, verify
that you have at least 500 MB of free disk on the /tmp directory. To check the available disk
space on the /tmp directory run the following command: df -h /tmp
3) To verify that the /tmp directory is mounted without the noexec option, run the following
command: sudo mount | grep '/tmp'
4) If the result is similar to the following example, it means that the issue exits in your OS:
/dev/xvda1 on /tmp type ext4 (rw,noexec)
5) Suspend the alerts and Put the jobs are off_ice

Migration overall plan using ASR:


1) We are have create the ASR and Run the ASR Agent on-primess server to replicate to Azure
Cloud.
2) Replication Depended upon the VM size , but it is acutlly one or 2 hours .
3) Uponcutover , we are going to powerdown the server in Vmare and Reboot the server in Azure
Vm, it will new ip in Azure Cloud Network
4) Check the NSG to allow the ports

Step by Step:
1) Verify that ASR configuration server can communicate with requried servers
2) Configure the repliacation to Azure Cloud
3) Configure the further server Details in Azure Cloud
4) Stop all the service on the server to be migrated
5) Initiate the Data sync to Azure
6) Powerdown the server on-primess server and poweron Azure cloud
7) Configure the DNS in Ipam to point new ip address on azure
8) Create the Recovery Service Vaults and enable backup
9) Remove the Netbackup,vmaretools,Montiorning agent tools

How to Create the Recovery Service Vaults:


ASR can migrate the server using Agent or Agent Less to Migrate the on-primess
Download The Mars Agent on the servers and install the On-primess server and Replicate the setting.
server to Azure Cloud

Site Recovery infrastructure - VMM Servers


https://forms.office.com/Pages/ResponsePage.aspx?
id=v4j5cvGGr0GRqy180BHbR2movJJumhJAnlM3ikajletUMTBMN0hJSlgxTFY5OU9ONzVHSFZTUEwyUS4u
============================================ASR Management===================

You might also like