Risk #1 — Technical
Description: SQL dialect differences in stored procedures cause silent behavioural changes during migration.
Impact: 4 · Likelihood: 5 (user flagged this — high certainty)
Mitigation: Build an automated diff harness that runs every stored procedure against both Redshift and Snowflake with the same input, comparing output row-by-row. Run for every procedure before cutover.
Contingency: If diff fails on a procedure, mark it for manual review and freeze its consumers until corrected.
Owner: Lead data engineer
Review: Weekly

Risk #2 — People
Description: 4-person team has no Snowflake production experience. Learning curve compresses the build window.
Impact: 3 · Likelihood: 4
Mitigation: Two engineers complete Snowflake certification in month 1 (paid course time). Bring in a Snowflake SE for the first month for design reviews.
Contingency: Engage Snowflake Professional Services for the optimisation phase if month 3 progress is < 60%.
Owner: BI lead
Review: Biweekly

Risk #3 — Vendor / 3rd-Party
Description: Snowflake billing model is consumption-based; cost forecasts may be off by 2-5× during testing.
Impact: 3 · Likelihood: 4
Mitigation: Set per-warehouse usage limits and budget alerts in week 1. Build cost-monitoring dashboard before workload migration.
Contingency: If burn rate doubles forecast at the 6-week mark, pause testing and re-baseline.
Owner: BI lead + Finance partner
Review: Weekly during testing phase

Risk #4 — Schedule
Description: 4-month timeline assumes parallel testing AND cutover within window. Realistic data-migration projects of this shape slip 20-30%.
Impact: 4 · Likelihood: 4
Mitigation: Lock the cutover date for end of month 4. Plan for parallel-run period (both Redshift + Snowflake live) to start month 3. Use parallel period as buffer.
Contingency: If at end of month 3 parallel-run shows < 95% consistency, extend parallel-run by 4 weeks and push downstream cutover.
Owner: PM
Review: Weekly

Risk #5 — Quality
Description: Data quality issues exposed by migration get blamed on Snowflake rather than the pre-existing source-system issues.
Impact: 3 · Likelihood: 4
Mitigation: Baseline data-quality metrics on Redshift in week 1. Surface a "pre-existing issue" log. Communicate proactively to stakeholders.
Contingency: For each migration-uncovered issue, document whether it existed in Redshift first.
Owner: BI lead
Review: Biweekly

Risk #6 — Stakeholder
Description: Business users continue running Redshift-style queries against Snowflake post-cutover, hitting performance issues blamed on the new platform.
Impact: 3 · Likelihood: 3
Mitigation: Run user-facing training in month 3. Provide a query-pattern translation cheat sheet. Identify and proactively rewrite the top 20 most-run queries.
Contingency: If first-week post-cutover complaints exceed baseline, run an emergency office-hours session with the BI team.
Owner: BI lead
Review: Monthly (acute during cutover month)

Risk #7 — Budget
Description: Snowflake consumption costs exceed budget once production workload migrates.
Impact: 3 · Likelihood: 3
Mitigation: Build cost forecasting on actual workload metrics from week 6+. Engage with Snowflake on annual commit pricing once forecast stabilises.
Contingency: Implement query-throttling on non-essential workloads if budget threshold hit by month 5.
Owner: BI lead + Finance partner
Review: Monthly

Risk #8 — Compliance
Description: Data classification + access controls in Redshift don't map 1:1 to Snowflake's RBAC model. Permission gaps slip through.
Impact: 4 · Likelihood: 3
Mitigation: Map every existing Redshift role/grant to Snowflake equivalents BEFORE first workload migrates. Run a security review at month 2.
Contingency: If review uncovers gaps, freeze workload migration until classification is restored.
Owner: BI lead + InfoSec partner
Review: Monthly

Risk #9 — Operational
Description: Existing reporting jobs that hit Redshift overnight have hardcoded credentials/endpoints that miss being updated for cutover.
Impact: 4 · Likelihood: 4
Mitigation: Audit every overnight job in week 2. Build a single connection-string config that all jobs read from. Switch the config at cutover, not the jobs.
Contingency: Have a rollback plan that flips the config back to Redshift if any job fails after cutover.
Owner: Lead data engineer
Review: Biweekly

Risk #10 — External
Description: Snowflake regional capacity / outage during cutover window.
Impact: 4 · Likelihood: 1
Mitigation: Pick a cutover window outside Snowflake's known maintenance schedule. Monitor Snowflake status page in the week leading up.
Contingency: If outage at cutover, defer cutover by 24-48h; do not force through.
Owner: PM
Review: Monthly (acute during cutover week)

Top 3 to act on this week:
1. Risk #1 (SQL dialect) — user flagged. Build the diff harness BEFORE anything else; everything else depends on knowing where the dialect bombs are.
2. Risk #9 (Operational — overnight jobs) — most likely to silently fail at cutover. Audit needs to start week 1.
3. Risk #2 (Team Snowflake skill) — has the longest mitigation lead-time (training). Start now or live with it.

— Risk register is a starting point. Your team will surface 5-10 project-specific risks in the first 2 weeks. Add them to this register and re-review weekly.