Migration Execution

AWS Database Migration Service (DMS) enables you to migrate databases to AWS with minimal downtime. DMS supports homogeneous migrations (Oracle to Oracle) and heterogeneous migrations (Oracle to PostgreSQL), making it a versatile tool for cloud migration projects.

Source and Target Endpoints define where data comes from and goes. DMS connects to over 20 database engines including Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, and Amazon RDS. Each endpoint requires connection information, credentials, and security settings. For on-premises databases, you typically deploy a replication instance in AWS VPC and establish connectivity via VPN or Direct Connect.

Replication Tasks are the core DMS components that move data. A task specifies the source endpoint, target endpoint, replication instance, and the tables or schemas to migrate. DMS provides two migration types: full load copies all existing data, and full load plus CDC performs initial copy then captures ongoing changes. CDC (Change Data Capture) reads database transaction logs to capture inserts, updates, and deletes in near real-time.

CDC Implementation requires specific database configurations. Oracle sources need Supplemental Logging enabled at the database level. SQL Server requires the SQL Server Agent service running and specific permissions for log reader access. MySQL binary logging must be enabled with ROW format. PostgreSQL requires logical replication slots. For example, when migrating an Oracle database to Aurora PostgreSQL, you enable Oracle supplemental logging, configure DMS with the appropriate CDC settings, and the service captures ongoing changes with sub-second latency.

Replication Instance Sizing impacts performance and cost. DMS offers several instance classes from dms.t3.micro for testing to dms.r5.4xlarge for production workloads. The instance must have sufficient CPU, memory, and storage to handle the volume of changes being captured. Monitor CPU utilization and memory usage during initial full load and adjust instance size if needed.

Data Validation is built into DMS through table statistics that compare source and target row counts. After migration completes, verify that all data transferred correctly. DMS also supports validation rules that can check specific column values or patterns. For critical migrations, implement additional validation using custom scripts that compare checksums or business-specific data integrity checks.

AWS Application Migration Service (MGN), formerly Server Migration Service, automates the migration of physical servers and virtual machines to EC2 instances. MGN provides a simple, automated approach that minimizes manual effort and reduces migration errors.

MGN Architecture uses a lightweight agent installed on source servers. The agent replicates block-level changes to AWS staging area subnet in near real-time, maintaining continuous synchronization. When you initiate a cutover, MGN converts replicated data into bootable EC2 instances. This approach enables testing and validation before cutover, reducing migration risk.

Agent Installation requires downloading the MGN agent for the source server operating system. The agent connects to AWS using a launch template that defines replication server settings. For physical servers, install the agent directly. For VMware virtual machines, use the MGN vCenter connector for automated agent deployment across multiple VMs simultaneously. A company migrating 100 VMware servers can deploy agents through the connector, reducing deployment time from days to hours.

Replication Configuration involves setting up replication templates that define how source volumes map to target EC2 volumes. Templates specify instance type, volume types, and networking settings. MGN automatically right-sizes EC2 instances based on source server specifications, with options to customize for each server. The replication process runs continuously in the background with minimal impact on source server performance.

Testing and Validation is a key MGN advantage. Launch test instances from replicated data without affecting production. Test instances run in an isolated staging network, allowing comprehensive validation of applications, connectivity, and performance. Validate that databases start correctly, application services function properly, and network configurations work as expected.

Cutover Planning involves scheduling the final sync and switching DNS or load balancer configuration to point to the new EC2 instances. MGN performs a final replication sync that typically completes in minutes, minimizing downtime. The cutover window depends on the final sync duration and DNS propagation time. For a typical web application, the cutover window might be 15-30 minutes.

Snow Family devices (Snowcone, Snowball Edge, Snowmobile) enable offline data transfer for scenarios where network bandwidth is insufficient. Snowcone provides 8 TB storage for smaller migrations. Snowball Edge offers 42-80 TB for medium transfers. Snowmobile delivers 100 PB capacity for massive data migrations. These devices are physically shipped to your data center, loaded with data, and shipped back to AWS for ingestion into S3 or other services.