AWS Application Migration Service, commonly referred to as MGN, and AWS Server Migration Service, known as SMS, represent two generations of migration tooling offered by Amazon Web Services. Both services were designed to help organizations move workloads from on-premises data centers or other cloud environments into AWS, but they were built at different times, with different architectural philosophies, and for different operational contexts. MGN is the current recommended service, while SMS has been officially deprecated and is no longer available for new customers as of March 2023.
Understanding what each service was designed to accomplish requires looking at the problem they both aimed to solve: lifting existing servers, applications, and operating system configurations from their current homes and replicating them into AWS with minimal disruption to ongoing operations. Both services approach this challenge through replication — continuously copying data from source machines to AWS — but the mechanics, supported platforms, scalability, and operational workflows differ in ways that matter significantly to organizations planning large-scale migrations.
The Origin and Development Timeline of Each Service
AWS Server Migration Service was launched in 2016 as a replacement for the even older EC2 VM Import tool. It was designed primarily for VMware vSphere, Microsoft Hyper-V, and Azure virtual machine environments, and it operated by taking incremental snapshots of source servers and transferring them to AWS as Amazon Machine Images. At the time of its release, it represented a meaningful advancement over manual import processes, and it served thousands of organizations during the early wave of enterprise cloud adoption.
AWS Application Migration Service was introduced in 2021, built on technology originally developed by CloudEndure, a company AWS acquired in 2019. CloudEndure had established a strong reputation for its continuous block-level replication approach, which offered faster recovery time objectives and more reliable replication than snapshot-based methods. When AWS integrated this technology as a native service under the MGN brand, it effectively signaled that the snapshot-based approach used by SMS had reached the end of its development roadmap, and the industry-standard path forward would be continuous replication.
Core Replication Architecture and Technical Methodology
The fundamental technical difference between these two services lies in how they replicate data from source to destination. SMS relied on snapshot-based replication, meaning it would capture a point-in-time image of a virtual machine’s disks at scheduled intervals and upload those snapshots to AWS. Each replication cycle produced an incremental snapshot that captured changes since the previous one. This approach worked adequately for workloads with low change rates but introduced challenges for busy servers where large volumes of data changed between snapshot windows.
MGN uses continuous block-level replication through a lightweight agent installed on the source server. The agent monitors the source disk at the block level and streams changes in near real-time to a staging area in AWS, where they are applied to a continuously updated replica of the source server. This approach means the replica in AWS is almost always current, with a recovery point objective measured in seconds rather than hours. When a cutover is initiated, the time required to launch the migrated server reflects only the seconds of data written since the last replication sync rather than hours of catch-up processing.
Agent Installation and Source Environment Requirements
SMS required no agent installation on source servers, which was one of its appealing characteristics for organizations with restrictive change management policies. Instead, it worked through connectors — virtual appliances deployed within the source environment that communicated directly with the hypervisor layer. The SMS connector for VMware environments interfaced with vCenter to access VM snapshots without touching the operating systems of individual servers. This agentless approach simplified the initial setup in tightly controlled environments but also limited the service to hypervisor-managed virtual machines.
MGN requires a replication agent to be installed on each source server. The agent supports a wide range of operating systems including Windows Server versions from 2003 onward and numerous Linux distributions. For physical servers, virtual machines across any hypervisor platform, and cloud instances from other providers, this agent-based approach offers far greater flexibility than the hypervisor-dependent SMS connector model. The installation process is straightforward and well-documented, and the agent operates with minimal performance impact on the source server during normal replication once the initial sync is complete.
Supported Source Platforms and Migration Scenarios
The scope of supported source environments reveals another significant difference between the two services. SMS supported only three source platforms: VMware vSphere, Microsoft Hyper-V, and Microsoft Azure virtual machines. This limitation made it unsuitable for organizations running workloads on physical servers, other public cloud providers, or less common virtualization platforms. For the enterprise environments common at the time of its release, this coverage was often sufficient, but it became a constraint as migration needs grew more diverse.
MGN supports a significantly broader range of source environments. Because it relies on an OS-level agent rather than a hypervisor connector, it can replicate physical servers, virtual machines on any platform including VMware, Hyper-V, KVM, and Xen, as well as instances running on Google Cloud Platform, Microsoft Azure, IBM Cloud, and other public cloud providers. This makes MGN suitable for heterogeneous environments where workloads are distributed across multiple infrastructure types, which accurately describes most enterprise IT portfolios undertaking large-scale migrations today.
Cutover Process and Downtime Management
The cutover process — the moment when production traffic shifts from the source server to the new AWS instance — is where the replication methodology differences have the most direct operational impact. With SMS, the cutover required finalizing the most recent snapshot replication cycle and then converting that snapshot into a running EC2 instance. Depending on the size of the server and the volume of recent changes, this process could take anywhere from tens of minutes to several hours, during which the application was unavailable or running in a degraded state.
MGN’s continuous replication approach allows for a much more controlled and faster cutover experience. Before initiating cutover, administrators can launch test instances from the current replica without interrupting replication, validating that the migrated server boots correctly, connects to dependent services, and functions as expected. When the actual cutover is initiated, MGN finalizes the replication sync, converts the staging instance to a launchable state, and starts the target EC2 instance — a process that typically takes only a few minutes. This dramatically reduces application downtime and makes it easier to schedule cutovers during narrow maintenance windows.
Scalability for Large Migration Projects
Organizations migrating dozens of servers can manage either service with relatively modest coordination effort, but the scalability differences become apparent when projects grow into hundreds or thousands of servers. SMS had a documented limit of 50 concurrent server replications per account, and managing large migration waves required careful scheduling and coordination to ensure servers were queued and processed efficiently. For enterprise migrations involving thousands of servers, this limit created bottlenecks that extended project timelines significantly.
MGN was designed with large-scale enterprise migrations in mind from the outset. It supports up to 3,000 concurrent server replications per region by default, with the possibility of requesting limit increases for even larger projects. The service integrates with AWS Migration Hub, which provides a central dashboard for tracking migration status across multiple servers, accounts, and AWS regions. This centralized visibility and the high concurrency ceiling make MGN operationally practical for the large migration programs that enterprise organizations typically run over periods of months or years.
Integration With AWS Migration Hub and Ecosystem Tools
AWS Migration Hub serves as the central coordination point for migration projects across multiple AWS services, and the level of integration each service maintains with this hub reflects their respective positions in the AWS service strategy. MGN is fully integrated with Migration Hub, allowing teams to track replication status, cutover progress, and post-migration validation for every server in a project from a single console. Migration Hub also integrates with partner tools for discovery, dependency mapping, and application portfolio assessment.
SMS had basic integration with Migration Hub for status tracking but lacked the depth of operational integration that MGN offers. The broader AWS ecosystem support for MGN also extends to integrations with AWS Systems Manager for post-migration configuration, AWS Launch Template customization for defining the target EC2 instance configuration, and post-launch actions that can automate software installation, configuration scripts, and validation checks immediately after a migrated server first boots in AWS. These automation capabilities reduce manual effort in the post-migration phase significantly.
Cost Structure and Pricing Considerations
AWS Application Migration Service is available at no additional charge for the first 90 days of replication per source server, which covers the typical duration of most migration projects. After 90 days, a per-server hourly replication fee applies. Customers are responsible for the underlying infrastructure costs associated with the replication staging area, including EC2 instances and EBS storage used during the replication process, but these costs are generally modest compared to the cost of the target environment itself. The absence of a licensing fee for the service itself makes MGN accessible for organizations of all sizes.
SMS was similarly structured with no direct service fee for the migration itself, though customers paid for the storage consumed by replicated AMIs in Amazon S3. However, because SMS is no longer available for new customers, its pricing model is largely a historical consideration. Organizations still running existing SMS replication tasks should note that they need to complete or migrate those projects to MGN, as the service infrastructure supporting SMS has been progressively wound down. Any cost comparison today is therefore an academic exercise rather than a practical decision point for new migration projects.
Security Controls and Data Protection During Replication
Data security during transit is a critical concern in any migration project, and both services address this through encryption. MGN encrypts data in transit between the source server and the AWS staging area using TLS, and data at rest within the staging area EBS volumes can be encrypted using AWS Key Management Service keys. This applies whether the source data is being replicated from on-premises or from another cloud provider, ensuring consistent protection regardless of network path.
SMS encrypted replicated data at rest within the AMIs stored in S3, but the transit encryption model depended on the connector configuration and the specific source environment. For organizations with strict data handling requirements — particularly in regulated industries — MGN’s more consistent and configurable encryption model offers clearer compliance alignment. IAM role-based access control governs which users and services can interact with MGN resources, and VPC configurations determine how replication traffic routes through the network, giving security teams granular control over the migration infrastructure.
Post-Migration Validation and Testing Capabilities
One of the most underappreciated advantages of MGN over SMS is its built-in support for non-disruptive test cutovers. Before committing to a final migration, administrators can launch a test instance from the current replication state, verify the migrated server’s functionality in the target AWS environment, and then terminate the test instance — all without pausing replication or affecting the source server in any way. This test-first approach dramatically reduces the risk of discovering critical issues only after a production cutover has already occurred.
SMS did not provide an equivalent test launch capability with ongoing replication. Validating a migrated server typically involved converting a snapshot to an AMI and launching it, but doing so was more disruptive to the replication workflow and required more manual cleanup afterward. The ability to run repeated test cutovers at any point during the replication lifecycle, as MGN supports, changes the risk profile of migration projects significantly. Teams can iterate on post-launch configuration scripts, validate application connectivity, and confirm performance characteristics before anyone has to commit to a production cutover window.
Practical Guidance for Teams Still Using Server Migration Service
Organizations that began migration projects using SMS before its deprecation face a practical decision about how to complete those projects. AWS has provided guidance recommending that any ongoing SMS replication be transitioned to MGN as soon as practical. The migration from one migration service to another requires setting up MGN agents on the servers currently being replicated by SMS and establishing a new replication baseline in MGN before discontinuing the SMS replication tasks. While this adds a short-term operational step, the long-term benefits of completing the migration under MGN — particularly the improved cutover process and ecosystem integration — justify the transition effort.
For servers that are close to their cutover dates and running stable SMS replication, completing the cutover under SMS before transitioning the remaining servers to MGN may be the most pragmatic approach. Teams should review AWS’s official deprecation documentation and support timelines to understand which SMS capabilities remain available and which have been fully retired. AWS support and the AWS Migration Acceleration Program can provide guidance for organizations with complex SMS-to-MGN transition scenarios that involve large server counts or specialized workload requirements.
Choosing the Right Approach for Modern Migration Projects
For any organization beginning a new migration project today, the choice between MGN and SMS is straightforward — SMS is no longer an option for new customers, and MGN is the designated standard service for lift-and-shift migrations to AWS. The relevant decision is therefore not which migration service to use but how to configure and operate MGN most effectively for the specific workload types, source environments, and timeline constraints of the project at hand.
That said, understanding what SMS was and how it differed from MGN provides valuable context for teams inheriting migration infrastructure they did not build, evaluating documentation from older migration projects, or assessing the maturity of migration tooling in general. The evolution from snapshot-based to continuous replication reflects a broader industry shift toward lower recovery point objectives and more operationally predictable migrations. MGN represents the current best practice, and building migration projects around its capabilities — including its test cutover functionality, automation integrations, and scalability — gives organizations the strongest possible foundation for moving workloads to AWS reliably and efficiently.
Conclusion
The comparison between AWS Application Migration Service and AWS Server Migration Service ultimately tells a story about how cloud migration tooling has matured over the past decade. SMS served its purpose well during the early enterprise cloud adoption wave, providing a structured, agentless path for moving virtual machines from VMware and Hyper-V environments into AWS at a time when such tooling was scarce. Its limitations — snapshot-based replication, narrow platform support, lower concurrency ceilings, and the absence of non-disruptive test cutovers — became more visible as migration projects grew in scale and complexity.
MGN addresses every one of those limitations through continuous block-level replication, broad OS and platform support, high concurrency capacity, deep ecosystem integration, and a test-first cutover workflow that meaningfully reduces migration risk. The fact that AWS officially deprecated SMS in favor of MGN is not simply an administrative product lifecycle decision — it reflects genuine technical and operational superiority in the newer service. Organizations that used SMS during its active years and are now completing or transitioning those projects should view the move to MGN not as a disruption but as an upgrade that improves every phase of the migration experience.
For IT leaders, cloud architects, and migration engineers planning workload transitions today, the takeaway is clear. MGN is the service to learn, configure, and operate. Investing time in understanding its replication architecture, agent deployment model, staging area infrastructure, and post-launch automation capabilities pays dividends in faster cutovers, lower risk, and more predictable project outcomes. As AWS continues to evolve MGN with new features and deeper integrations across its migration ecosystem, the gap between it and any legacy alternative will only grow wider, making early and thorough adoption of MGN the strategically sound path for any organization committed to a successful cloud migration program.