# On-premise Server Migration to AWS using AWS Application Migration Service (MGN)

# Introduction:

Migrating physical or virtual machines from on-premises to AWS can feel scary but <mark>AWS Application Migration Service (MGN)</mark> makes it straightforward by continuously replicating servers to AWS and enabling test launches and cutovers with minimal downtime. Let’s start from planning to post-cutover validation.

# Architecture Diagram

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764503321822/c50fac73-3b4c-4c5e-8526-94426a09df77.jpeg align="center")

# Procedure:

### Step 1: Configure replication in AWS MGN

* Open the **AWS Application Migration Service** console.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044091757/fce9445a-202f-4b2c-8db1-c3ec511e52c6.png align="left")
    

Confirm **Replication settings**:

* Under settings select the **Replication template** and click on edit.
    
* Select the **subnet** for replication instance and **instance type** based on your requirement.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044230871/ec18099c-79b2-4194-98a3-1dc40c349770.png align="center")

* Choose EBS volume type and Encryption method.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044382172/c6cc1c17-103b-4505-8314-9247aef4b7d2.png align="center")
    
* Save the template
    

Now, Select the **<mark>Lunch template</mark>** under <mark>Settings</mark>.

* Edit the template
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044540085/8e953115-eb11-41be-983e-255be6efba6c.png align="center")

* Choose the EBS volume type, **security group** and **EBS volume type**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044578176/72123f28-d849-4369-bc0f-c37341881c8e.png align="center")

* Save the template.
    

Under <mark>Post-launch template</mark>

* Select the install the system manager agent and allow exectuting actions on launch servers.
    
* Also, choose the **Deployment option** for agent to be installed on.
    
* save the template.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044700533/70b18061-3b26-46ec-ac38-8f26b8648364.png align="center")

### Step 2: Agent installation

The agent registers the server to your MGN service and starts sending block-level data to replication servers in your AWS account .

Now, Select the **Source servers** and click on **Add server.**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764044865185/4486718f-4849-4bc0-9ba9-19ef0b25b1bc.png align="center")

* Select the Operating system, replication preferences and
    
* Provide the **AWS Access key ID** and **Secret Access Key**, you can generate form **IAM** if you haven’t generated it yet.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764045417597/1c53ef9b-0625-4de6-bcf0-764056af5826.png align="center")

* Copy the Installer link and paste on the browser of your physical machine, it will download an installer file.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764046940785/e9eb82c4-2d06-48fd-bc67-9fa50025195e.png align="center")

<mark>Note: </mark> remember you need to download the **<mark>exe file not .sha512</mark>**

* Copy the Command below the installer download link and paste on the same directory where your installer is downloaded.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764584877686/bc9f89e8-3909-44bc-b8dd-6471be3050bc.png align="center")

* In the MGN Console you should see the source server appear (with a discovered source ID).
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764057118039/22be1256-98be-48ee-9a2b-0d3b73bc8509.png align="center")

* Wait for the lifecycle to complete
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764057164526/d10fd593-7ba6-4391-8f91-3ea4e0edd690.png align="center")

* Wait until replication progress is 100%.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764057195464/058ad582-a49f-452a-b4ac-b18c898688a2.png align="center")

* We can see the specification of physical machine on the server info
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764062468647/33e9b065-e20c-4e70-9e81-22fca5fe7d3a.png align="center")

* After successful replication, the <mark>Lifecycle </mark> moves to **Ready for testing stage**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764142453696/81660e3e-37ed-49de-94d7-ed7d9c1451e8.png align="center")

* The new ec2 server creation for AWS Migration Service Replication Server is visible.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764142515054/df211745-817f-46fb-8601-70dd25a4350c.png align="center")

### Step 3: Verifying the Templates

On the AWS Application and Migration Serve on source server

* Go to the <mark>launch settings</mark> and **modify EC2 launch Template**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764142636011/b53cac2f-bd97-4459-adb4-5f87644923e1.png align="center")

* It will redirect to the **EC2 launch template**
    
* Under Key Pair <mark>select or create</mark> a **new key pair**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764142812954/bee8837b-1226-4f40-85de-381fc83bed58.png align="center")

* Under **Advanced network configuration** **Enable** <mark>Auto-assign public IP</mark>
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764142852195/dc3efc94-80a3-4aca-88a5-afa8c090dbbd.png align="center")

* Select the **template** and choose **Set default version** from the **Action**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764143075261/9276bdd3-770f-4efd-a13b-b090d6a33d53.png align="center")

* Choose the recent version
    
* It’s now visible that default version is changed to 3 from 2.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764143203838/6b78e93c-836a-4151-871c-77c50a91f9ba.png align="center")

### Step 4: Launch the Testing Instance

On the Migration Dashboard

* Select <mark>Test and cutover</mark> and as Lifecycle is **Ready for testing, Lunch test instances.**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764143880394/3a9fb84a-37de-47cb-8fc1-1a0feb1af1f1.png align="center")

* Lunch the test instance
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764143997102/3f34f7ca-606d-406a-bac7-23c2a55ed1c0.png align="center")

* View the events on the launch history on the left sidebar, wait until it’s completed.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764144064935/577d9acd-2c28-4e90-830d-68cfc62917fc.png align="center")

* The **job logs** and **Lifecycle** for an update.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764144391983/5d02d273-eb5d-43f8-a64e-40109ffc2c98.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150161672/c8617c64-88e5-4922-9a9c-35213da140a7.png align="center")

* As the test instance is launched, now open the RDP port of the instance and you can connect it through the RPD
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764149721051/ba51aa32-b038-4c8f-a935-a80cf43d96bf.png align="center")

* Select the test instance and under **Security**
    
* Click on **security group,** **edit it** and
    
* Add the **RDP port**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764149698794/aac2bee3-9def-4d81-8481-a3c45037dcae.png align="center")

* Select the instance and click on connect
    
* Only copy the **public DNS** and use the <mark>username and password</mark> of the <mark>On-prem server.</mark>
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764149919306/5fc9e4ff-8f6f-46e1-ae53-6de15ef7e3bf.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150032883/03950ca9-9ebc-4e15-994a-62a417e8ec17.png align="center")

* All the files of on-premises on the ec2 test-instance is replicated, if everything is Perfect, we will start the final cutover.
    

### Step 5: Lunch Final Cutover Instance.

* Go back to **AWS Application Migration** server and mark ready for cutover.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150207083/172ab240-275f-497a-8445-fa5ac7f401bf.png align="center")

* If you find something unusual or all your data was not migrated, you can Revert to <mark>“Ready for testing“</mark> and ensure sync completed before <mark>“Lunch Test Instances”</mark>.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150448425/edef511e-2cfa-4cef-b4f1-e5abca36a225.png align="center")

* You can see that when you changed to Ready for cutover the Test-Instance is automatically deleted.
    
    Now for Cutover,
    

1. **Schedule downtime** or maintenance window for the application (short maintenance window reduces final delta).
    
2. In MGN Console, **Perform Cutover** for selected servers:
    
    * MGN will perform a final sync (brief pause for consistent state).
        
    * Launch the target EC2 instance(s) in AWS.
        

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150341813/d976880d-bc89-4abc-a3e3-ada72e0c3fc6.png align="center")

* As the Lifecycle moves to the <mark>Ready for cutover</mark>,
    
* From the **Test and cutover** option, click on <mark>“Lunch cutover instance”</mark>
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150518798/10d1a99e-abf3-4064-90cd-8a54d3c60435.png align="center")

* Wait until the cutover is completed. Meanwhile you can see the Jobs and logs from lunch history
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150802757/45f2b6ae-b452-4fb8-97a5-4e768ac0f1a8.png align="center")

* Job logs.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764150828170/271d7701-8758-4a44-8ca8-dd18360f5726.png align="center")

* After the Cutover is completed, as we can see on the Lunch history.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764152659925/4ab92da1-eab9-4f90-af3e-6f80e526475e.png align="center")

* We can see that the <mark>Final instance</mark> has been created on the **EC2 Instances**.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764152714069/aab75024-f826-4f5c-8c51-afae0fff1e7c.png align="center")

* Now, we need to finalize the cutover after testing the Instance so that we can shutdown the source and Replication server.
    
* Click on the <mark>Finalize cutover</mark> from the “**Test and Cutover”** Option.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764152838188/60d878fe-8db6-4755-b935-4edb3cb8703a.png align="center")

* Lifecycle transition from the **Cutover in profess** to **Cutover complete** after Finalize.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764153031931/7d0594d7-59f5-4971-aea5-13a6927fe82a.png align="center")

* After everything is completed next step is <mark>mark as archived</mark> the **source server** as it is already disconnected from the service when we finalize the cutover.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764153109141/c66566c5-6f23-4994-ae63-3a5a13f62a53.png align="center")

* we can see that only one instance is running tha is our **final Cutover Production server** migrated from the on-premises. Let’s connect it through the RDP
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764153209326/5230841c-52a2-4586-9bbc-6c5d54bb7195.png align="center")

* Copy the <mark>public-dns</mark> of the server and use the on-premises username and Password.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764153337280/6955f839-990a-4dbf-a58f-077d0c590a65.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1764153444841/7ca1c640-4f40-4bf9-8414-2596f942cf93.png align="center")

we have migrated the On-premise server to the AWS using AWS Application Migration Service (MGN).

## Final tips and best practices

* **Start small**: do with a noncritical server to learn the process.
    
* **Document everything**: replication settings, custom drivers, any changes to server configurations.
    

# Conclusion

AWS Application Migration Service (MGN) simplifies moving on-prem servers to AWS by providing continuous block-level replication, safe test launches, and an easy cutover path. With good planning and careful testing, we can migrate mission-critical workloads with minimal downtime with predictable results.