Configuring AWS DMS for homogeneous SQL migrations
Moving an on-premises SQL estate to AWS does not have to mean a weekend of downtime. AWS Database Migration Service can copy a schema, bulk data and subsequent changes between matching database engines, giving administrators a controlled route for SQL Server, MySQL or PostgreSQL migrations.
Start with an Australian deployment decision: Sydney (ap-southeast-2) and Melbourne (ap-southeast-4) are both available, but the right region still depends on latency, data-residency obligations and support arrangements. Budget in Australian dollars, including GST effects, and test whether your SD-WAN can reach the selected VPC without making the database public.
Choose the right migration method
| Method | Source and target | Ongoing changes | Suitable use |
|---|---|---|---|
| Homogeneous DMS | Same engine, such as SQL Server to SQL Server | Database-native log capture | Controlled migration with a short cutover |
| Heterogeneous DMS | Different engines, such as Oracle to SQL Server | Log capture and schema-conversion tooling | Engine replacement or substantial mapping |
| Native backup and restore | Typically the same engine on RDS or EC2 | Not continuous by itself | Archive moves and straightforward refreshes |
Use homogeneous DMS when the source and target run the same engine. Schema conversion is unnecessary, and native change logs can carry inserts, updates and deletes after the initial copy. Check version compatibility by rehearsing the move with the production schema and representative data.
The need for a rehearsed, staged release in real estate website design has a parallel in database migration: test with recent data, record timings and agree on a rollback point before touching the primary system.
Prepare source databases for change capture
For SQL Server, enable CDC on each table that must move, then verify that the capture jobs run and that log retention can cover a slow full load. PostgreSQL normally needs logical decoding with wal_level set to logical and a suitable publication; MySQL needs binary logging in ROW format, with binlog_row_image set to FULL. Test these prerequisites rather than assuming a successful endpoint test proves CDC will work.
Choose a full load followed by ongoing CDC when the business needs a short cutover. DMS seeds the target from the source, records changes made during the load and then catches up. Exercise the workload first: large indexes, batch jobs and sudden write bursts can extend the load, fill transaction logs and increase replication lag.
Keep source backups in place until validation is complete. If change capture is paused, work out how long the database can retain the required transaction records; otherwise an overloaded source disk can become the first failure. Monitor free space on both database hosts alongside replication latency.
Build secure AWS connectivity
Place the DMS replication instance in private subnets and keep public access disabled. It needs a route to the source database and target endpoint, plus HTTPS for AWS APIs through a NAT gateway or VPC endpoints. Use security groups. Typical ports are 1433 for SQL Server, 3306 for MySQL and 5432 for PostgreSQL, but match the actual configuration and size the instance for concurrent tasks and sufficient log storage.
Create the migration IAM role first, trusting the DMS service principal and granting only required permissions. Store database credentials in AWS Secrets Manager where supported, and use TLS with a trusted certificate for the database connection. Verify name resolution and routes from the replication instance, not merely from an administrator laptop.
A practical IP reputation filtering reference is useful for application-edge protection, while DMS itself needs explicit allow-lists and least-privilege network access. In a hybrid Australian environment, inspect any SD-WAN or transit path carrying migration traffic and confirm that return traffic is permitted.
Configure and run the migration
In the DMS console, create the replication instance, then define source and target endpoints. For each endpoint, select the engine, version, port, SSL mode and authentication method. Use the RDS endpoint or private DNS name of the target, not a public address, and test it from the replication server. Test both endpoints before creating a migration project.
Within the migration project, attach the endpoints and choose the appropriate full-load and CDC settings. Start with current data, then enable replication of ongoing changes; this avoids trying to reconcile every business transaction manually. Exclude unmigrated operational tables deliberately rather than discovering them during cutover. Capture the task configuration for repeatability.
Watch CloudWatch and the DMS task logs throughout the load. Record errors, throughput and change-processing delay, not just percentage complete. A load can look healthy while CDC is falling behind. Before cutover, compare table counts and sampled values while accounting for concurrent writes. Correct schema incompatibilities, network faults or oversized transactions before proceeding.
Cut over, validate and retire old resources
At the agreed cutover, stop or queue application writes, wait for the final captured changes to reach the target, and check for DDL not captured by CDC. Update the application’s connection configuration or DNS, then restart connections. Run business-level tests as well as row counts: an order lookup, a login and a representative financial transaction can expose problems that a schema comparison misses.
Do not schedule a Friday arvo change without checking the clock. Sydney operates on AEST or AEDT, while Perth and Brisbane remain on UTC+8 with no daylight saving, so an apparently generous window can disappear quickly. Coordinate teams in local working hours, publish the change in Australian Eastern Time and daylight-saving dates, and retain the old database through the agreed observation period.
Once the application has proved stable, remove DMS endpoints and the migration project, then decommission the replication instance once its shutdown is approved. Revoke temporary firewall rules and credentials, apply final backups, and tag or delete leftover AWS resources to control the Australian cloud bill. Retain logs, validation results and the rollback decision for audit.