AWS Database Migration Service

The outage that stops migrations happening

Moving a database sounds like copying data. The difficulty is time.

A straightforward migration means stopping the source so nothing changes, copying everything, pointing applications at the target, and starting again.

For a small database that is an evening. For a substantial one it is many hours, and hours of unavailability is something few organisations will accept for a system that matters.

The result is that migrations get postponed. The database that should have moved years ago stays where it is, because nobody can find a window long enough.

Copying while the source keeps running

AWS DMS addresses this in two phases.

Full load. Existing data is copied from source to target. The source stays in use throughout, so this takes as long as it takes without anyone waiting.

Change data capture. Changes occurring on the source after the load began are captured and applied to the target. The target continues to track the source.

The consequence is what matters. Once the initial load finishes and ongoing replication catches up, the target is current and staying current.

Cutover then becomes a short operation. Stop writing to the source, let the last changes apply, point applications at the target. Minutes rather than hours.

That difference is frequently what makes a migration possible at all.

Testing on data that is real

A second benefit follows from the same mechanism, and it is underrated.

A target that is populated and receiving live changes can be tested against before anything depends on it.

The application can be pointed at it in a test environment. Queries can be run and compared. Performance can be measured on realistic volumes rather than on a sample.

Compare this with a migration performed in one window, where the first time anyone sees the application running on the target is during the cutover, with no time to investigate anything surprising.

Changing engine

DMS supports migrations between different database engines, not only between instances of the same one.

This matters for modernisation programmes moving from commercial engines to open source ones, which is a common motivation.

An important distinction applies here. The service focuses on moving data. Schema objects, stored procedures and application code written for one engine's dialect are a separate problem, addressed by a separate tool, and the documentation describes how they are used together.

That division reflects reality. The data is the tractable part. The accumulated procedural code is where migrations between engines actually spend their effort.

Where difficulty appears

Problems in these migrations rarely come from rows failing to arrive. They come from differences the data does not carry with it.

Data types that do not correspond exactly, where a value fits but loses precision. Character encodings that mangle certain characters. Date and time handling that shifts values. Constraints or defaults expressed differently.

None of these announce themselves. They are found by comparing migrated data against the source and by running the application against the target.

This is why a migration approach allowing extended verification is worth more than one that is merely fast. The time to find these issues is while the old system still works.

Who uses it

AWS DMS is used by database administrators, platform teams and migration projects moving databases into AWS. It appears in cloud migration programmes, in engine changes, and wherever a database has to move without a long outage.

Points to consider

DMS is an AWS service and the official documentation is the reference for supported sources and targets, limitations and pricing.

Replication instances are sized and cost while running. A migration is not free, and the instance has to be adequate for the volume and change rate.

Ongoing replication has requirements of the source. Capturing changes depends on source configuration such as logging settings, and the documentation states what each supported source needs.

Validation is necessary regardless of what the service provides. Comparing data and testing the application are the steps that establish a migration succeeded, and skipping them because a tool reported success is how problems reach production.

Getting started

The official documentation covers supported endpoints, task configuration, selection and transformation rules, and validation. Running a migration for one non critical table, with ongoing replication enabled, demonstrates the mechanism and what change capture requires of the source.