A source-to-target field map is the one artifact where a SQL Server EDW and its Snowflake replacement have to agree on what the data means. Get it right and the build is mechanical. Get it wrong and every downstream report inherits the error — silently.
The load-bearing artifact
Every other migration document describes the work. The field map is the work — it's the only place the legacy schema, the new schema, and the business meaning are reconciled in one row.
Code conversion, data foundation build, and report migration all resolve back to it. When the mapping is complete and signed off, the engineers know exactly what to build and the analysts know exactly what will change. When it's ambiguous, the ambiguity doesn't disappear — it gets resolved by whoever writes the SQL, quietly, without the business in the room. That's how a migration that "passed testing" still breaks trust on go-live day.
Anatomy of one row
One row of a field map is a contract between two systems and several teams. Each cell closes a specific question — and each is a place the migration can go wrong. Select a cell to see what it carries and what the TPM owns there.
↓ Select any cell
Where it breaks
01 · Grain mismatch
Source is one row per opportunity per daily snapshot; target is modeled as one row per opportunity. Join it wrong and every sum inflates by the number of snapshots.
Caught by: stating grain explicitly on both sides of the row, before anyone writes a join.
02 · Silent type coercion
MONEY carries 4 decimal places; a careless cast to NUMBER(18,2) truncates fractions of a cent across millions of rows. No error is thrown. The totals are just quietly wrong.
Caught by: pinning target precision and scale in the row, then reconciling sums to tolerance.
03 · Orphaned downstream reports
A Tableau workbook binds to [CloseAmt]. The target renames it CLOSE_AMOUNT_USD. Nothing warns you — the report just returns null or fails to refresh after cutover.
Caught by: tracing every field to its downstream consumers as part of the map, not after.
04 · Ownership ambiguity
Two teams read the same source field differently — "close amount" is booked vs. forecasted revenue. Without a named owner, the disagreement surfaces at UAT, not design.
Caught by: a business owner per row who signs off on the meaning, not just the plumbing.
05 · Assumed referential integrity
Snowflake accepts PRIMARY KEY and FOREIGN KEY constraints but doesn't enforce them. Orphan rows the source database would have rejected now load clean into the target.
Caught by: moving integrity checks out of the schema and into the reconciliation suite.
SQL Server → Snowflake · the realities the map surfaces
These aren't the engineer's problem to solve alone — they're the risks a TPM has to know exist, so the map plans for them and the schedule sizes them. A sample of what the row has to account for:
The manager's seat
Get the source SME, the target architect, and the report owner to agree on what each field means before it's built. The map is the forcing function for that conversation.
When two teams disagree on a definition, the TPM runs it to a decision and records it — so it's resolved by the business, once, not by whoever codes it, repeatedly.
No object exits design until every field is mapped, typed, owned, and signed off. Percentage-mapped becomes a tracked, reportable measure of real progress.
Every transformation and every assumed constraint becomes a reconciliation test. The map isn't just a build spec — it's the definition of "done" for go-live.
From the field
On a revenue-data platform migration, I owned the source-to-target mapping and the cross-team coordination around it. The workbook became the program's single source of truth — and its per-object sign-off gate. Objects didn't move until the business owner had signed the meaning, not just the mapping.
// Generalized from hands-on work — details defensible in conversation
Take the artifact
The reusable structure behind this page — source object and field, type and grain, transformation logic, target, validation rule, and owner — as a workbook you can adapt to your own migration.
↓ Field-mapping workbook · templatePlaceholder link — the workbook is the next artifact to build.