Which solution will satisfy these requirements with minimal operational overhead?
Use AWS Server Migration Service (SMS) to create and launch a replication job for each tier of the application. Launch instances from the AMIs created by AWS SMS. After initial testing, perform a final replication and create new instances from the updated AMIs.
Create an AWS CLI VM Import/Export script to migrate each virtual machine. Schedule the script to run incrementally to maintain changes in the application. Launch instances from the AMIs created by VM Import/Export. Once testing is done, rerun the script to do a final import and launch the instances from the AMIs.
Use AWS Server Migration Service (SMS) to upload the operating system volumes. Use the AWS CLI import-snapshot command for the data volumes. Launch instances from the AMIs created by AWS SMS and attach the data volumes to the instances. After initial testing, perform a final replication, launch new instances from the replicated AMIs, and attach the data volumes to the instances.
Use AWS Application Discovery Service and AWS Migration Hub to group the virtual machines as an application. Use the AWS CLI VM Import/Export script to import the virtual machines as AMIs. Schedule the script to run incrementally to maintain changes in the application. Launch instances from the AMIs. After initial testing, perform a final virtual machine import and launch new instances from the AMIs.
Explanations:
AWS Server Migration Service (SMS) is designed for server migration and supports continuous replication, which meets the requirements for synchronizing changes and minimizing downtime. It enables the company to create replication jobs for each tier and perform a final sync before production cutover, satisfying all requirements with minimal operational overhead.
While VM Import/Export can migrate VMs, it lacks built-in support for continuous synchronization of changes, so it does not meet the requirement for real-time synchronization before the final cutover. Managing incremental updates through a script would also increase operational overhead.
This option separates the migration process for the operating system and data volumes, adding complexity. AWS SMS alone could handle both root and data volumes with continuous replication, so importing data volumes separately withimport-snapshotis unnecessary and increases operational complexity.
Although AWS Migration Hub and Application Discovery Service help with discovery and grouping, they do not offer a continuous synchronization feature. VM Import/Export also does not support real-time sync, and maintaining updates via scripting adds overhead, making this approach unsuitable for minimizing downtime.
I draft that the answer is:
Use AWS Server Migration Service (SMS) to create and launch a replication job for each tier of the application. Launch instances from the AMIs created by AWS SMS. After initial testing, perform a final replication and create new instances from the updated AMIs.
From what I’ve seen, the answer is:
Use AWS Server Migration Service (SMS) to create and launch a replication job for each tier of the application. Launch instances from the AMIs created by AWS SMS. After initial testing, perform a final replication and create new instances from the updated AMIs.