Migrating VMware virtual machines to AWS with SMS
Moving VMware workloads from an Australian data centre to Amazon Web Services requires more than copying virtual disks. The migration must account for application dependencies, identity services, firewall rules, licensing, backup policies and the timing of the final cutover. AWS Server Migration Service (SMS) was designed to simplify this process by replicating on-premises virtual machines into Amazon Machine Images and staging instances.
SMS is a legacy AWS service, and AWS now recommends Application Migration Service (MGN) for most new projects. However, many infrastructure teams still encounter SMS in existing runbooks, older migration programmes or environments where the tooling has already been configured. Understanding its workflow remains useful when maintaining or completing those projects.
A successful migration begins in vCenter rather than the AWS console. Administrators need an accurate inventory of guests, operating systems, virtual hardware, storage consumption and network relationships. A lightly used file server may be straightforward, while a domain controller, SQL Server or latency-sensitive application can require a carefully sequenced migration.
Australian organisations also need to consider data residency and privacy obligations. Choosing the AWS Asia Pacific (Sydney) Region, or Melbourne where available for the required services, can help keep workloads closer to users and within an approved geographic boundary. The Privacy Act 1988, contractual controls and sector-specific requirements should be assessed before replication starts.
What AWS Server Migration Service does
AWS SMS uses an on-premises connector appliance that communicates with vCenter and AWS. The connector discovers virtual machines, creates replication jobs and transfers VM data to Amazon S3. AWS then produces AMIs from replicated snapshots, which can be launched as EC2 instances for testing or cutover.
Replication is incremental after the initial synchronisation, reducing the amount of data transferred during later cycles. SMS does not automatically redesign an application for cloud operation. It reproduces a server, so administrators remain responsible for right-sizing the EC2 instance, selecting EBS volumes, rebuilding network controls and validating application behaviour.
The service is best suited to relatively conventional VMware guests with supported operating systems and predictable storage. Workloads using special hardware, unsupported drivers, unusual boot configurations or tightly coupled clusters need additional planning and may be better candidates for a different migration method.
Assess the VMware estate first
Start with a dependency map rather than a list of VM names. Record DNS records, static addresses, service accounts, scheduled tasks, certificates, mounted shares, database connections and outbound integrations. Group machines by application so that migration waves preserve their startup and shutdown order.
Collect CPU, memory, disk latency, network throughput and peak usage over several weeks. vSphere data can reveal whether a VM is oversized or regularly constrained. For environments using Distributed Resource Scheduler, DRS performance metrics can expose placement and contention issues before they become cloud sizing errors.
Classify each guest as rehost, retire, rebuild or replace. A legacy Windows server might move unchanged for a short-term transition, while an old monitoring appliance may be better replaced with a managed AWS service. This classification prevents the migration from becoming a simple transfer of technical debt.
Prepare the AWS landing zone
Create the target VPC before replicating anything. Define public and private subnets across multiple Availability Zones, route tables, security groups, network ACLs, DNS behaviour and connectivity to the remaining data centre. A VPN over the internet may suit a pilot, while Direct Connect is more appropriate for stable production traffic and predictable throughput.
Use separate accounts or organisational units for shared services, security, development and production. Establish CloudTrail, Config, central logging, GuardDuty and backup policies before the first server is launched. IAM roles should follow least privilege, with temporary administrative access preferred over permanent credentials.
Select an Australian Region based on service availability, latency, resilience and compliance requirements. Sydney is commonly the primary choice for local workloads, while Melbourne can support selected designs and recovery objectives. Check the current AWS service matrix rather than assuming every feature is available in both locations.
Configure replication safely
Install the SMS connector on a supported virtual machine with access to vCenter and outbound connectivity to AWS endpoints. Use a dedicated vCenter account with only the permissions required for discovery and replication. Validate time synchronisation, proxy settings, DNS resolution and firewall rules before registering the connector.
In the SMS console, import or discover the required VMs, assign replication settings and create a replication job. Choose an appropriate license model, subnet and IAM role for the generated AMIs. Large disks and high-change-rate databases can consume considerable bandwidth, so schedule the initial synchronisation outside peak periods where practical.
Do not treat a completed replication job as proof that the application is ready. Review generated AMIs, device mappings, boot mode, disk types and security group assignments. Confirm that the target instance type supports the guest operating system and that encrypted EBS volumes use the intended AWS Key Management Service keys.
Test before the production cutover
Launch a test instance into an isolated subnet and prevent it from conflicting with the production machine. Check boot behaviour, Windows activation or Linux services, application configuration, local firewall rules, DNS registration and monitoring agents. Test both internal dependencies and external connections such as email relays, payment platforms and partner APIs.
For databases, validate transaction consistency and recovery procedures rather than simply checking that the service starts. Application owners should perform functional tests using realistic workflows. Record test results, defects and rollback actions in a migration runbook that can be followed by an on-call engineer.
Plan the cutover around the application’s recovery point objective. Stop or quiesce the source VM, complete the final replication, launch the target instance and update DNS or load-balancer records. Reduce DNS time-to-live values in advance, but remember that cached records can still persist beyond the stated TTL.
Operate the migrated workload
After cutover, monitor CPU, memory, EBS latency, network flow logs, application response times and failed authentication events. Install or validate the CloudWatch agent where deeper operating-system metrics are needed. Remove temporary test security group rules and document the final architecture.
Hybrid operation is common during a staged migration. Keep routing, DNS forwarding, identity services and firewall policies consistent while some systems remain in the VMware cluster. Avoid overlapping IP ranges, particularly when offices in Sydney, Melbourne or regional sites connect through existing MPLS, SD-WAN or VPN infrastructure.
Cost controls should be active from the first day. Apply tags for owner, environment, application and cost centre, then use AWS Budgets and Cost Explorer to track EC2, EBS, data transfer and snapshot charges. Australian teams should also account for GST treatment, software licensing terms and support coverage across local business hours.
Decide whether SMS is still appropriate
SMS can be useful for completing an established legacy workflow, especially when the objective is a basic VMware-to-EC2 rehost. For a new migration, MGN generally offers a more current agent-based approach and a broader set of operational controls. The decision should be based on support status, workload characteristics, testing evidence and the required cutover process.
| Consideration | AWS SMS | AWS Application Migration Service |
|---|---|---|
| Replication model | VMware connector and snapshot-based replication | Installed replication agents |
| Best fit | Existing or legacy SMS projects | New lift-and-shift migrations |
| Cutover approach | Launch replicated AMIs as EC2 instances | Continuous replication with test and cutover workflows |
| Operational status | Legacy service; verify current availability | AWS-recommended migration service |
| Planning focus | Connector, vCenter access and replication jobs | Agent deployment, staging area and cutover orchestration |
| Suitable outcome | Basic server rehosting | More controlled, repeatable migration waves |
Whichever tool is selected, keep the source VMware VM intact until the AWS workload has passed acceptance testing, backup validation and a defined observation period. A migration is complete when the application is supportable, recoverable and costed correctly—not merely when an EC2 instance is running.