Snowflake Migration Assessment Checklist

1. Define the migration decision before collecting inventory

Start by writing the decision the assessment must support: whether to migrate a specific warehouse or domain to Snowflake, which workloads belong in the first migration wave, whether a replatform, partial redesign, or full transformation is required, what must be proven before the legacy platform can be decommissioned, and which constraints are fixed — regulatory controls, outage windows, data residency, contractual dates, or downstream dependencies.

Without a clear decision, discovery tends to produce a large spreadsheet rather than a usable migration plan.

Record the business outcomes separately from the technology choice. A new platform does not, by itself, resolve conflicting metric definitions, unclear data ownership, fragile upstream feeds, or unused reports. Those issues need explicit disposition: migrate, redesign, retire, or defer.

2. Build an inventory that follows dependencies

Count-based inventory is not enough. Ten independent tables may be simpler than one table fed by nested procedures and consumed by dozens of scheduled reports. Capture dependencies in the order data actually moves.

For every object, identify both upstream and downstream relationships. A dependency graph is more useful than a flat asset count because it reveals migration waves and shared failure points.

3. Classify each workload instead of assuming one migration path

Assign every workload a disposition. This classification prevents the common mistake of treating migration volume as the number of objects copied. The meaningful unit is a workload with its code, data, dependencies, consumers, controls, and owner.

• Rehost: move with limited functional change when the design is already fit for purpose.
• Refactor: preserve the business outcome but change SQL, models, orchestration, or storage design.
• Replace: move the requirement to an existing Snowflake-native or governed platform capability.
• Retire: do not migrate an unused, duplicated, or obsolete asset.
• Retain temporarily: keep a source workload during a phased transition when immediate migration creates unnecessary risk.

4. Score conversion and operating risk

Use a consistent risk model so the proof of concept and migration waves are selected deliberately.

Do not hide uncertainty inside an average score. A single unresolved critical dependency or missing regulatory control can block a wave even when the rest of the workload is straightforward.

5. Choose a proof of concept that tests uncertainty

A proof of concept is useful when it reduces a named risk. Select a workload that is representative enough to test the migration method but bounded enough to complete without becoming the first production wave by accident.

Define success criteria before the proof of concept begins. A demonstration that data can be loaded is not evidence that the migration can be operated, reconciled, or cut over safely.

• Can the most difficult SQL or procedure pattern be converted with acceptable behavior?
• Can the selected ingestion pattern meet the required freshness and recovery behavior?
• Can source-to-target validation be automated at the necessary depth?
• Can the target security model reproduce the required access boundaries?
• Can a representative BI or downstream consumer run correctly against the target?
• Can the team observe failures and recover without manual guesswork?

6. Design validation before building the target

Snowflake's migration guidance distinguishes data movement from data validation and describes validation as the way to establish confidence before cutover. Your assessment should define the evidence required at several levels.

Set tolerances and exception rules before execution. “Numbers look close” is not an acceptance criterion. If some differences are expected because the target intentionally changes business logic, document those changes and obtain explicit approval.

7. Define the target operating controls

The assessment is incomplete if it describes only the build. Document how the target will be run after cutover. The operating design should have named owners: a control with no owner is a recommendation, not an implemented safeguard.

• Account, environment, database, and schema boundaries.
• Role hierarchy and least-privilege access.
• Storage integrations and secret ownership.
• Warehouse sizing, auto-suspend behavior, and resource-monitor policy.
• Deployment and change-management path.
• Data-quality checks and freshness monitoring.
• Incident ownership, escalation, and recovery procedures.
• Cost monitoring and accountability.
• Backup, retention, recovery, and audit requirements.

8. Plan migration waves around business risk

Group workloads into waves using dependencies and business criticality, not simply by schema or team. A practical wave plan usually starts with a bounded pilot carrying representative technical risk, then lower-criticality workloads that exercise the repeatable migration factory, then shared or high-value domains once tooling and evidence are stable, and finally highly coupled or regulated workloads after rehearsals prove the control model.

For every wave, record entry criteria, exit criteria, validation owners, cutover method, rollback conditions, and the earliest permitted decommission date.

9. Make cutover and rollback testable

Write the production cutover as an ordered runbook with timestamps, owners, evidence, and stop conditions.

Rehearse the sequence with a representative workload. If the rollback path cannot be tested, record that limitation as a decision risk rather than assuming it will work during an incident.

• Schema-change control before the window.
• Historical-load completion and reconciliation.
• Final incremental or CDC catch-up.
• Source and target freshness checks.
• Technical and business acceptance evidence.
• Consumer connection changes and monitoring during the stabilization window.
• Rollback triggers and the exact return path.
• Criteria for ending dual-running and decommissioning the source.

10. Use explicit go/no-go gates

The assessment should end with a decision table, not a generic recommendation. A “no-go” result is useful when it identifies the exact evidence needed to proceed. It protects the program from committing to a date before the architecture and acceptance model are ready.

What the assessment should deliver

Apply the data migration cost estimation guide to turn the assessed workload, validation, and wave model into a traceable estimate.

A decision-ready Snowflake migration assessment produces a dependency-aware workload inventory, a migrate/refactor/replace/retire disposition for every workload, a risk register with named owners, a target architecture and operating-control outline, a proof-of-concept plan tied to specific uncertainties, a validation matrix with baselines, tolerances, and approvers, a migration-wave roadmap, a rehearsable cutover and rollback approach, a cost and capacity model with explicit assumptions, and a go/no-go decision with the conditions attached to it.

If your assessment cannot support those outputs, it is still discovery — not yet a migration plan.

Primary documentation

Verify Snowflake behavior against current primary sources: Snowflake data migration and validation (https://docs.snowflake.com/en/migrations/aim-for-datawarehouses/data-migration-validation/overview), the Snowflake COPY INTO table reference (https://docs.snowflake.com/en/sql-reference/sql/copy-into-table), and the Snowpipe overview (https://docs.snowflake.com/en/user-guide/data-load-snowpipe-intro).

Frequently Asked Questions

Read next — Data Engineering