DMS full-load task settings

Three groups of settings on a DMS replication task decide what happens to the target tables before the load, what happens when the load finishes, and whether the result is checked. They are easy to set by eye in the console and each has a failure mode that only appears later.

Target table preparation

TargetTablePrepMode controls what DMS does to a target table before it starts writing. DROP_AND_CREATE recreates the table from the source definition, TRUNCATE_BEFORE_LOAD keeps the table and empties it, and DO_NOTHING leaves it exactly as it is.

DO_NOTHING is the right choice when:

1. The target tables were created deliberately, with partitioning, indexes or storage parameters that DMS would not reproduce.
2. Existing data in the target has to survive the load.
3. The target is a view or a materialized view.
4. Constraints or triggers on the target must stay in place.
5. The load is incremental into tables that already hold data.

The cost of DO_NOTHING is that DMS is no longer responsible for the target being empty. If a task stops and resumes abruptly during the full load phase, DMS may write rows it has already written, so the target needs a primary key or unique index and a load path that tolerates a repeat. Starting a task with the reload option does not help here either: DMS applies TargetTablePrepMode before reloading, so with DO_NOTHING the tables must be truncated by hand first.

In a multi-stage migration where the second task reads a pre-built cross-database view into a target table that already has the right shape, DO_NOTHING is the setting that matches the intent — DMS is being asked to populate a structure, not to own it.

Stopping after the full load

Two settings decide what happens when the initial load finishes, and they differ in what they do with the changes captured while it was running.

StopTaskCachedChangesApplied: true — DMS performs the full load, caches the changes occurring on the source meanwhile, applies those cached changes once the load completes, and then stops. Use it for a one-time migration that has to be consistent as of the moment the task stopped, rather than as of the moment the load started.

StopTaskCachedChangesNotApplied: true — DMS performs the full load, still captures changes during it, then stops immediately without applying them. Use it when only the initial snapshot is wanted: the changes will be handled by a different process, the migration has further stages that should not see mid-flight updates, or the loaded data is to be inspected before anything else is applied to it.

For ongoing replication, set neither. A task created with --migration-type full-load-and-cdc and both settings false continues into CDC once the initial load and its cached changes are applied.

Data validation

Validation makes DMS compare source and target rows after the full load rather than trusting that the load succeeded. It costs time and adds read load on both ends, and it is the only thing in a DMS task that will tell you the data is wrong.

Turn it on for any load whose result matters. Turning it off is a decision about a specific table under a specific time constraint, not a default — a migration validated only by row count will pass with silently truncated strings and rounded numerics, which are exactly the Oracle to PostgreSQL type-mapping failures most likely to occur.