Most migrations don't fail on load day. They stall at sign-off, when the person asked to approve the move can't get a straight answer about why the numbers differ.

The data is rarely the real problem. The problem is that five basic questions were never answered in writing. So every difference becomes a debate, and the debate happens in the sign-off meeting.

Answer these five before your next mock load or parallel run. Not after it.

1. The key: which field says two records are the same record?

You can't compare two systems until you agree what makes a record on one side the same record on the other. Get this wrong and everything after it is wrong too: you get false breaks, or worse, false matches.

It is rarely a single ID. New systems often generate new IDs, so the key is usually a combination of business fields.

A good written answer names the fields on both sides and says what happens when a key isn't unique. For example: "A trade matches on trade date + instrument identifier + portfolio code. Source column TRD_DT maps to target column trade_date. Any key that appears more than once on either side is reported as an error, not matched."

2. The tolerance: how big a difference is acceptable?

Systems round differently, store dates differently and convert currencies at different points. With no agreed tolerance, every rounding difference is a break and the real breaks hide in the noise. With a loose one, real errors pass.

A good answer sets the rule per type of field. Text must match exactly. Dates are converted to the same format and time zone, then must match. Amounts match within a stated tolerance. Counts match exactly.

And for amounts, write down two tolerances, not one. Here's why.

Worked example. A tolerance of 0.01 per line sounds safe. Now take 10,000 lines, each 0.004 out. Every single line passes. But 10,000 × 0.004 is 40.00, so the total is 40.00 out. A check with only a per-line tolerance reports "all matched" while the balance doesn't tie.

So the written answer looks like: "Amounts: 0.01 per line, and a separate tolerance per account total, agreed with finance."

3. The expected differences: which ones are known, and why?

Some differences are there by design. A code list was remapped. A field was retired. Closed accounts before an archive date are not migrated. A rounding rule changed.

If these aren't listed up front, they look exactly like defects. Someone investigates the same known difference on every run, and the sign-off pack fills up with things nobody needs to worry about.

A good answer is a short list where each item has the rule, the reason and who agreed it. For example: "Status code C in the source becomes CLOSED in the target. Accounts closed before the archive date are not migrated, so expect them as missing in the target. Agreed by the finance systems lead."

4. The owners: who owns each unexpected difference?

A difference without an owner stays open. "The data team" doesn't investigate breaks. People do.

A good answer gives a name, not a team, for each category of difference, plus when they will respond. For example: "Records missing in the target: the migration lead. Amount breaks above tolerance: the finance systems analyst. Reference data mismatches: the data owner for that domain. First response on every break within one working day." Write the actual names in your version.

5. The evidence: what will the person signing off actually look at?

The person signing is not going to read a 40-tab workbook. If they can't see the result clearly, they can't defend the decision later, when an auditor or the board asks how they knew the data was right.

A good answer describes the evidence before it exists:

  • records in the source and in the target, and how many matched
  • unmatched records on each side
  • breaks by category, against the agreed tolerance
  • expected differences, each with its reason
  • open items, each with an owner
  • which run it came from: date, input files and rule version, so it can be run again

Not only migrations

The same five questions apply in business as usual. When you change an ETL pipeline, a report or a data model, you need to prove the output still matches: old output against new output. Same key, same tolerances, a list of the differences the change is meant to cause, named owners, and evidence the person approving the release can read.

Put it on one page

Here's the simplest way to use all of this. Before the sign-off meeting, give the person signing one page with five boxes: the key, the tolerances, the expected differences, the owners and the evidence summary.

One page, sent before the meeting, not a workbook sent after it. Sign-off is a decision, not a test result, and that page is what the decision rests on.

If any box is empty, the sign-off meeting will be about that box.