Delta Migration After the Initial Load in Six Steps

Delta Migration After the Initial Load

How banks move the changes made after the initial load: fix the start point, capture every change including deletes, apply them in order, reconcile each delta and drain the last one.

Alexander Kiel

Business Analyst · Banking & Wealth Management

05.09.2026 · 8 MIN READ · DATA MIGRATION

ON THIS PAGE

1. Fix the Delta Start Point

2. Capture Every Change Including Deletes

3. Apply Changes in Commit Order

4. Rehearse Every Delta Cycle

5. Reconcile Each Delta Separately

6. Drain the Final Delta at Cutover

Sample case: Deutsche Bank (Postbank)

In short

FAQ

A delta migration moves the changes made after the initial load: new accounts, bookings, closed positions and corrected addresses. As Martin Kleppmann puts it, a one-off snapshot of the database is not enough. You also need the stream of writes that follows. In a bank, it never stops before cutover.

Change is also where incidents start. The FCA found that failed technology changes account for a quarter of all high severity incidents that cause harm to consumers and the market. A delta that misses a delete or applies an update twice is such a failure.

The initial load gets most of the attention. The delta decides whether the new platform starts with today's data or last month's. How does your bank capture, apply and prove every change made after the initial load?

Illustrative timeline of a delta migration in a bank, from the initial load through three shrinking deltas to the final delta at cutover, with the final delta highlighted

STEP 1

Fix the Delta Start Point

Every delta needs a start point: the exact moment the initial load read the source. Record it as a log position or a timestamp for each table, not as a date in the project plan. A gap of a few seconds loses bookings, while an overlap applies them twice.

Open transactions make this harder. AWS notes that transactions committing during the load become cached changes that are applied afterwards. If the tool stops waiting for long transactions, the ones that run past its timeout are missed in the future replication. My article on data migration strategy shows where the initial load fits in the overall plan.

✓

Record a log position or timestamp for each table

✓

Check for open transactions before the initial load starts

✓

Store the start point with the evidence of the load

Could your team name the exact log position where your last initial load began?

Keep in mind: A start point set for the whole database can hide gaps where tables were loaded hours apart.

STEP 2

Capture Every Change Including Deletes

There are three ways to find changes: a last-modified timestamp, a full compare of source and target, or change data capture from the database log. Timestamps miss deleted rows, because a deleted row leaves no timestamp to read. A full compare finds records that exist in the target but are missing from the source, but reads every table again.

Log-based capture records inserts, updates and deletes. In SQL Server, it reads the SQL Server transaction log. It must be enabled before tracking starts. By default, three days of data are retained. A delta run that waits longer finds the oldest changes already removed.

✓

Use log-based capture for tables with frequent deletes

✓

Enable capture before the initial load starts, not after

✓

Check how long the change tables keep their data

Which of your source tables lose deleted rows without leaving any trace for the delta?

Keep in mind: Some legacy systems delete rows in overnight batch jobs. Ask the application team before you trust timestamps.

STEP 3

Apply Changes in Commit Order

Changes must reach the target in the order they happened. An account must exist before its first booking. A closed position must not reopen because an older update arrived late. In the initial load, a child table might load before its parent table. In the delta, the same risk applies to every transaction.

Tools offer two modes. Transactional apply applies the transactions in the same commit order as the source. Batch apply is faster, but you must deactivate the foreign keys, even during the change data capture (CDC) phase. Some tools reduce a delta to its end state. SQL Server returns one net change row for each source row changed if the table has a primary key or unique index.

✓

Load parent records such as clients before their accounts

✓

Use transactional apply for bookings and positions

✓

Use net changes only for tables with stable keys

What happens in your target when a booking arrives before the account it belongs to?

Keep in mind: Net changes hide the steps in between. Keep the full change history where auditors need every step.

STEP 4

Rehearse Every Delta Cycle

Rehearsals usually test the initial load. Test the delta too: run the load, let the source change for a few days, then apply and measure the delta. Record how many changes arrived, how long they took and which failed. Each rehearsal should shrink the final delta. In a decommissioning project I worked on, we split large applications into several load waves, so archiving processes kept running while the data moved.

Latency is the measure to watch. AWS defines it as the delay between when a change was committed on the source and when the change was replicated to the target. One task setting stops the task after full load but before AWS DMS applies cached changes, so the team can check the load first.

✓

Measure the daily change volume for each table

✓

Time how long each delta takes to apply

✓

Pause after the load to check it before the delta

How long would your final delta take to apply if cutover were this weekend?

Keep in mind: Month-end and year-end can produce more changes than an ordinary day. Rehearse a delta that includes one.

STEP 5

Reconcile Each Delta Separately

A reconciliation of the total after cutover can hide errors in the delta. A missing booking and a duplicated one can cancel each other out in a balance. Reconcile each delta on its own: counts of inserts, updates and deletes per table, plus sums of amounts and positions, compared between the change log and the target.

Validation tools help, but timing matters. AWS DMS begins comparing the source and target data immediately after a full load and uses the task latency to avoid false alarms while changes are still on their way. In a validation only task, no data is migrated, which suits a final check. My article on reconciliation automation shows how to run such checks every day.

✓

Count inserts, updates and deletes per table and delta

✓

Compare sums of balances and positions, not only counts

✓

Investigate every break before the next delta runs

Can your team prove that every change in the last delta reached the target?

Keep in mind: A clean total can hide two errors that cancel each other out. Check the individual records too.

STEP 6

Drain the Final Delta at Cutover

The final delta runs when the source stops taking writes. AWS describes the offline approach plainly: reads can continue, but the write traffic must be stopped. With continuous replication, downtime stays short: the team waits until latency reaches zero.

The guidance sets the order: When the source and target databases are in sync, verify the data. Only then do users switch. Plan for the work in flight as well. Payment orders, trade instructions and client requests that arrive while writes are stopped need a queue and an owner. My article on the operational readiness check covers the go-live decision itself.

✓

Stop all writes to the source before the final delta

✓

Wait until replication latency reaches zero

✓

Queue orders that arrive while the source is closed

Where do client orders go while your old platform no longer accepts writes?

Keep in mind: Batch jobs and interfaces also write to the source. Switch them off too, or the delta never ends.

Change Data Capture: The Magic Wand We Forgot | Martin Kleppmann (Associate Professor @ University of Cambridge)

SAMPLE CASE

Deutsche Bank (Postbank)

In 2023, Deutsche Bank moved Postbank customers onto its own IT platform in waves. The last wave covered about four million contracts of two million customers. Services were restricted from Friday 30 June at 17:00 to Monday 3 July at 14:00. In total, the bank moved around 19 million product contracts of around 12 million Postbank customers.

Problems followed. On 29 September 2023, BaFin appointed a special representative to ensure that the bank processes its customers’ orders within a reasonable time and quickly works through its backlog of outstanding customer orders. Chief executive Christian Sewing said the bank had underestimated how many customer inquiries the IT integration would cause.

Complaints to BaFin about banks rose 87% to more than 27,000 in 2023, which Reuters linked to the Postbank integration. The data move was completed, but the backlog of orders was still open three months later.

Key takeaway: A delta migration ends only when the work around it is cleared too. Plan how orders arriving during the final delta are queued, processed and checked. Staff up for extra client contact.

"We have not lived up to our responsibility here."

Christian Sewing (CEO @ Deutsche Bank)

In Short

A delta migration turns a snapshot into a live copy. Fix the start point, capture every change including deletes, apply changes in commit order and rehearse until the final delta is small. Reconcile each delta on its own and stop all writes before the last one runs.

Cutover then becomes a short, measured step: the source is closed, the delta is drained, the data is proven and every order that arrived in between has an owner.

Frequently Asked Questions

What is a delta migration?

A delta migration moves the changes made to source data after the initial load was taken. The initial load copies a snapshot of the data at one moment, while the delta brings the target up to date. Banks often run several deltas between rehearsals and cutover, with the final one when the old system stops taking writes.

What is the difference between a delta load and a full load?

A full load copies all records from the source, whether or not they have changed. A delta load copies only the records that were inserted, updated or deleted since the last load. Full loads are simpler to check but take longer and grow with the data. Delta loads are faster but need a reliable way to find every change, including deleted rows.

What is change data capture?

Change data capture, or CDC, records inserts, updates and deletes as they happen, usually by reading the database transaction log. A migration tool then applies these changes to the target in commit order. CDC finds deletes that timestamp-based loads miss and keeps the target close to the source, so the final delta at cutover stays small and quick to apply.