Library · Data Practice OS
Migration wave plan
Template · Published · Source reviewed
Use after Migration assessment. One row per workload (a report family, an ETL flow or a subject area), not per table. The Migration pattern is chosen per row, not for the whole estate.
1. Workload inventory and treatment
| ID | Workload | Legacy components (jobs, procs, reports) | Consumers | Value (H/M/L) | Effort (H/M/L) | Treatment | Target data product | Depends on | Wave |
|---|---|---|---|---|---|---|---|---|---|
| WL-01 | retire / rehost / replatform / refactor / rebuild |
Treatment guide
| Treatment | Use when |
|---|---|
| Retire | No active consumer in 6 months, or duplicated by another workload. Retire before you migrate |
| Rehost | Lift as-is, for short-lived or low-value workloads you will retire soon |
| Replatform | Convert code with tooling (SnowConvert AI, Lakebridge) into dbt models with minimal redesign |
| Refactor | Logic is sound but the model is not; remodel into medallion layers and data products |
| Rebuild | Logic is unknown or wrong; extract Business rules first, then build from the rules |
2. Wave sequencing rules
- Wave 0 (foundations): landing zone, identity, network, catalog, CI/CD, one thin end-to-end pipeline.
- Wave 1 (pilot): one workload with high value, medium effort, few dependencies and a willing business owner. It proves the playbook.
- Later waves group workloads that share sources, so each shared source is ingested once.
- Move consumers with their data. Do not leave a report pointing at legacy with its data migrated.
- Use the Strangler fig pattern: switch off legacy pieces as each wave exits.
3. Wave register
| Wave | Workloads | Business owner | Start | Parallel run window | Cutover target | Legacy decommission date | Status |
|---|---|---|---|---|---|---|---|
| 0 | Foundations | Platform lead | n/a | n/a | |||
| 1 |
4. Entry criteria (per wave)
- [ ] Workloads inventoried, with consumers confirmed by name
- [ ] Business rules extracted and reviewed for rebuild/refactor items (Extracting business rules)
- [ ] Every in-scope rule has an id and priority; P0 rules have a pinning test (Tracing rules from legacy code to modern code; proposed)
- [ ] Target data product canvases drafted (Data product canvas)
- [ ] Reconciliation approach agreed (Reconciliation and cutover checklist)
- [ ] Sources ingested into bronze
- [ ] Business owner has signed up to the parallel run and sign-off
5. Exit criteria (per wave)
- [ ] Parallel run completed for the agreed window, with every run reconciled
- [ ] Reconciliation sign-off by the business owner
- [ ] Traceability gap report clean: no rule not migrated, none migrated on faith, no undecided suspected defects (Traceability gap report and rule trace card; proposed)
- [ ] Consumers repointed and confirmed
- [ ] Legacy jobs disabled, then decommissioned after the agreed hold period
- [ ] Run cost compared with legacy and recorded
- [ ] Lessons folded into the playbook
6. Risks and debt log
| Risk / debt item | Wave | Impact | Mitigation | Owner |
|---|---|---|---|---|