A practical readiness framework for mid-market finance and BI teams about to move a warehouse, swap ETL stacks, or stitch silos together. Built from postmortems of 40+ enterprise migrations — half of which went sideways before anyone wrote a single SQL view.
By the time someone asks "should we move off this warehouse?", the system has usually been running for 6–12 years. Three CFOs ago, somebody hard-coded a tax rule into a stored procedure. Nobody remembers. And that's the cheap part.
The CFO dashboard pulls from a view that joins seven tables — two of them deprecated, one populated by a Friday-night Python script on a laptop under someone's desk. Migrating this isn't engineering. It's forensic work.
Stored procedures have no LinkedIn. When the last engineer who understood the ETL left, the knowledge left with them. Documentation says "TODO: explain this." The migration team will rediscover everything the hard way.
Schema changes look low-risk on a sprint board. Then audit season hits and the reconciliation script can't find `gl_2019_archive`. Now you're explaining to the auditor why Q3 numbers shifted by 0.4%.
The framework isn't original — most pieces have been kicking around in data-engineering postmortems for years. What's new is putting them in one place, weighting them by how often they actually kill migrations, and giving you a number you can defend in a steering committee meeting.
For your top 20 reports: do you know every table they touch, including transformations? If you'd need a week to find out, score yourself low.
How often does the source schema change? Once a quarter is workable. Once a sprint, with no migration script, is a tax you'll pay forever.
The finance team will lose a week of close. Sales ops will lose access to their pet dashboard. If they don't know yet, you're not ready.
If the cutover goes wrong on a Tuesday at 4pm, can you be back on the old system by Wednesday morning without losing data? "We've never tested it" counts as a zero.
Reconciling a $200M revenue table by eyeballing two dashboards is not testing. You want row counts, hash checks, and sample audits — automated and runnable on demand.
Migrations done as a side project alongside two roadmap commitments fail. We have not seen one succeed. Honesty about capacity is half the battle.
Pick a number from 0 to 10 for each row. If you can't decide, pick the lower one — that's the answer. Add the totals at the bottom. The weighting column is there so you can argue with us later.
Max weighted score: 180. Below 100 — postpone and fix fundamentals. 100–140 — green light with named risks. Above 140 — proceed and keep this page bookmarked for the next migration.
"The cheapest migration is the one you finish documenting before you start coding. Nobody believes this until their second migration."— Director of Data Engineering, retail group (12,000 employees), in a 2024 postmortem we ran
We've watched smart internal teams burn nine months trying to do their own warehouse cutover because asking for outside support felt like an admission of failure. It isn't. Migration is a specific muscle, and most BI teams don't get reps often enough to build it.
If your readiness score lands below 100 and the deadline isn't movable, the math usually favors an external data warehouse consultancy taking the heavy lifting while your team owns the institutional knowledge. We've seen this combo cut delivery time by roughly a third, mostly by avoiding the rookie mistakes a seasoned migration team has already made on someone else's project.
And — important caveat — this isn't always the answer. If your score is above 140 and you've done this before, bringing in outside help can slow you down. The framework is meant to make that call obvious, not push you in one direction.
No. We've applied it across Snowflake, BigQuery, Redshift, Synapse, and a couple of on-prem Oracle setups that refuse to die. The pillars don't change. The tooling under each pillar does, and the framework workbook has a vendor-matrix appendix for the most common moves.
The self-score takes nine minutes if you're honest. A proper assessment — interviewing report owners, auditing lineage, dry-running a rollback — is usually 2 to 4 weeks of part-time work for a small team. Plan for closer to four if your environment is older than five years.
Not at all. We've had teams pause mid-project, run the assessment, and discover three blockers they'd been about to slam into. The cost of a one-week pause is almost always lower than the cost of a failed cutover.
Yes — the download bundle has the framework PDF, the weighted scoring sheet in Excel and Google Sheets format, and three sample postmortems (anonymized) so you can see what failure modes look like in practice.
Stackline Field Notes is a small editorial side-project run by data-platform practitioners. We write things we wish we'd had when we were doing the work. The framework draws on migration retros from finance, retail, manufacturing, and one very memorable agricultural co-op.
The full bundle — framework PDF, weighted scoring sheet, and three anonymized postmortems — is free. No phone number required. We'll send it to a work email and leave you alone.
Send me the workbook