A migration timeline is a reconciliation timeline

Ask a team how long their warehouse migration will take and the answer is usually built from the conversion work. Count the tables, count the stored procedures, apply a rate, add contingency. That estimate is incomplete, because it covers only the part of the project that is straightforward to size.

The work that sets the cutover date is proving that the new platform returns the same answers as the old one. That is reconciliation, and it rarely appears as a line item in the first estimate.

Why conversion estimates hold and cutover dates slip

Conversion is tractable. Schema translation follows patterns, and once a team has handled twenty views of a particular shape the twenty-first takes very little time. Conversion tools do real work on the repetitive parts. Even hand-written procedural logic converts at a rate the team can measure after the first few weeks, once it has a feel for the source dialect.

Reconciliation behaves differently. You cannot estimate it from a count of objects, because the effort is driven by the number of differences you find and by how hard each one is to explain. A single unexplained difference in a regulatory report can hold a cutover for days while the teams involved work out which of the two numbers was right in the first place.

Reconciliation also tends to be scheduled after conversion, which means it starts late and under time pressure. By the time anyone is comparing outputs, the go-live date has been communicated to the business, and every finding from that point has to be resolved inside a fixed window.

What reconciliation actually involves

Comparison runs at four levels, and each level catches a different class of problem.

Row counts catch missing and duplicated data, and they cost almost nothing to run. Run them first, across every table in scope. A matching count says nothing about whether the values inside the rows agree.

Aggregate comparison catches most arithmetic and join problems. Sum each measure by two or three dimensions on both platforms and compare the results. A changed join type or a null handled differently usually appears here.

Full column-level comparison is the expensive one, and it is the only level that proves a report is correct. Compare the result sets of the actual reports, column by column and row by row, over a defined period. Reserve it for the reports that matter. Running it across an entire estate is rarely affordable and rarely necessary.

Point-in-time comparison applies wherever a report can be regenerated for a past date. Getting today's number right is a weaker test than it looks. A platform can return the correct figure this morning and still fail to reproduce what was published for a quarter that has already closed. Snowflake Time Travel covers a short retention window, so anything older has to be compared against archived output from the legacy platform.

Differences are the normal outcome

A first reconciliation run usually produces more differences than the team expects. Conversion errors account for some of them, and differences in engine behavior account for most.

A large share of what we see falls into a few recurring categories: null handling that differs between the two engines, implicit type coercion that the legacy engine performs and the new one does not, rounding applied at a different point in the calculation, date boundaries interpreted in a different time zone, and sort order that was never deterministic and happened to be stable on the old hardware.

Some differences turn out to be defects in the legacy platform that nobody had noticed, because there had never been a second implementation to compare against. Those are the awkward ones. Fixing them changes a number the business has been using for years, so the decision belongs to the report owner and to finance, and it takes time to reach. That conversation is manageable eight weeks before cutover and very difficult inside the freeze window.

Building the harness early

We recommend building the comparison harness in the first weeks of the project rather than near the end. It does not need to be sophisticated. A harness that runs a defined workload against both platforms, stores both result sets, and produces a difference report a person can triage is enough. It can be a set of dbt models writing both result sets into a comparison schema, with the legacy output exported as files.

Once it exists, each object can be reconciled as soon as it is converted. The difference log then accumulates steadily. Left to the final month, all of that work has to happen at once, in the part of the schedule with the least room to act on what it finds. The team also gets an early measure of its own conversion quality.

A reconciliation report signed by the report owners is also what makes the cutover decision defensible later. When an internal audit asks why the platform was trusted on the day it went live, that signed report is the answer.

What to write into the plan

If you are scoping a migration, make the following points explicit before the estimate is agreed.

Name the reports that will be reconciled at full column-level detail, and have the people who own those reports sign off on the list. That list drives most of the validation effort. Where it stays open, reports get added through the project and the validation budget is spent without anyone deciding to spend it.

Decide in advance what counts as an acceptable difference. Some differences will be accepted without a fix, because the new behavior is the more correct one. Write down who is allowed to make that call, and record each decision against the report it affects.

Allow time between the end of reconciliation and the cutover date. Late findings are normal. Where the plan has no gap, an ordinary finding delays the launch. On a mid-sized estate, two weeks is usually enough.

The conversion work stays the same size. Running reconciliation from the start moves the uncertain part of the project into the months where the schedule can still absorb a late finding.