Key takeaways
- Treat migration as understand, clean, map, test, validate, and go live.
- Data quality, go-live planning, and training are common preventable failure points.
- Run the old and new process in parallel for 2 to 4 weeks.
- Retire old spreadsheets for migrated functions so staff do not drift back.
Why is migration more than copying data?
A timetable migration changes how planning data is understood, cleaned, mapped, tested, validated, and then used at go-live. Copying spreadsheet rows without those steps carries old errors into the new process.
Start by understanding what the current spreadsheets contain and which functions are moving first. Then clean and map the data before any go-live decision.
What belongs in a phased migration plan?
Use the verified sequence as the backbone of the plan.
- Understand the current spreadsheet process
- Clean the data before migration
- Map fields from the old structure to the new one
- Test the migrated data
- Validate that the result is fit to use
- Go live with trained staff and a defined retirement point for old spreadsheets
How should the parallel run work?
The parallel run gives planners time to compare the migrated process against the old one before go-live settles.
- Choose the migrated functions that will be tested in parallel.
- Run old spreadsheets and the new process side by side for 2 to 4 weeks.
- Compare outputs and investigate differences.
- Fix data-quality and mapping issues found during the run.
- Train the staff who will use the migrated functions.
- Retire the old spreadsheets for those functions after validation.
Why must old spreadsheets be retired?
If the old spreadsheets stay active for migrated functions, staff can revert to the familiar process. That creates two live sources for the same work.
Retirement should be part of go-live planning. The team needs to know which functions have moved and which files are no longer authoritative.
Where do data quality and training fit?
Data quality must be addressed before migration, because missed issues become migration failures. Training must happen before go-live, because untrained staff are a known preventable risk.
Connect this work to data preparation and the rollout work in stakeholder rollout.
What decision does this guide support?
This guide answers one question: how should a school phase the move from spreadsheets without a disruptive cutover? It does not compare products or rank migration tools.
The useful decision is whether the team has cleaned, mapped, tested, validated, trained, and planned retirement of old files before go-live.
Questions planners ask about phased migration
Why not do a big-bang cutover?
The verified guidance says a big-bang cutover is the fastest path to disruption. A phased approach gives time to test, validate, and train.
How long should the parallel run last?
The sourced guidance gives 2 to 4 weeks as the parallel-run window before retiring old spreadsheets for migrated functions.
What causes migration failure?
The common preventable causes are data-quality issues missed before migration, thin go-live planning, and untrained staff.