wtf( )unctionsystem design, drawn
← all problemsAWS SA ProHard

Two cutover plans, and the six weeks nobody replicated

The migration has been running for six weeks. Change data capture has kept the target within seconds of the source that whole time, validation passes, row counts match, and the team is ready to cut over on Saturday.

The source did not stand still for six weeks. Two indexes were added for a slow report, a column got a default, a stored procedure was rewritten, and a new service account was granted read on three tables.

Both plans cut over to a target holding every row. Choose the one that is still running on Monday.
!Row counts match exactly and the application falls over within an hour of cutover — first a report that times out, then a permission error from a service nobody remembered.Ongoing replication moves table DATA. The things that changed here are not table data, and nothing in the task's status will say so.
Design ATrust the task — it has been in sync for six weeks

Boundaries, outermost first: The source, still live: Source database (DDL too) The target: Target database (rows only) Outside every boundary: DMS task (data only), Schema drift (nobody did) Connections: Source database calls DMS task — rows DMS task calls Target database Schema drift must NOT reach Target database — never arrives

Source databaseDDL too
DMS taskdata only
Target databaserows only
Schema driftnobody did
Design BRe-apply the schema drift before cutting over

Boundaries, outermost first: The source, still live: Source database (DDL too) The target: Target database (rows + DDL) Outside every boundary: DMS task (data only), Schema drift (replayed) Connections: Source database calls DMS task — rows DMS task calls Target database Schema drift controls Target database — re-applied by hand

Source databaseDDL too
DMS taskdata only
Target databaserows + DDL
Schema driftreplayed
Two designs, one brief. Read both, then choose the one that meets it.