Key takeaways
- Migration runs understand, clean, map, test, validate, go live, in that order.
- Each stage earns the next: nothing goes live unvalidated.
- Run the old and new process side by side for 2 to 4 weeks before you commit.
- Set a retirement date for the old spreadsheets, or staff will drift back to them.
Six stages, one rule
Understand, clean, map, test, validate, go live. The rule is that each stage earns the next: unmapped data does not get tested, untested data does not get validated, and nothing goes live unvalidated.
Understanding comes first because spreadsheets hide structure. Before anything moves, you need to know which files are current, which functions they serve, and which of those functions move in this phase.
Plan the parallel run
The parallel run is the test that matters: the new process against the old one, on live planning work, for 2 to 4 weeks.
- Pick the functions being migrated in this phase.
- Run the old spreadsheets and the new process side by side for 2 to 4 weeks.
- Compare outputs and chase every difference to a cause: data, mapping, or process.
- Fix what the run exposes, then check the fix in the following week.
- Train the staff who will own the migrated functions.
- Retire the old spreadsheets for those functions on a named date.
Retire the old files, on a date
If the old spreadsheets stay live after migration, staff return to the familiar tool, and the school ends up running two versions of the same work. That recreates the version drift the migration was meant to end.
Retirement belongs in the go-live plan: which files stop being authoritative, on which date, and who tells the people who use them.
How to do this in Smootables: import your Excel data
Import data
Column mapping
Smootables imports timetable data from Excel or CSV files through a four-step wizard, so the clean-map-test loop runs in the product rather than in scripts.
- Open Import data in the top navigation. The wizard runs Destination, File, Mapping, Confirm.
- Choose what the file contains: Resources (teachers, rooms, groups), Teaching offering (list of study units), or Full period plan (resources + teaching offering + lesson amounts).
- Use Download template if you would rather fill a clean structure than map a legacy file.
- On the Mapping step, check the suggested column mappings and set any column you do not need to Don't import (skip column).
- Read the preview before confirming: it counts the teachers, groups, rooms, and placements the import will create and lists validation errors found in the file.
Where migrations actually fail
The preventable failures share a shape: a data-quality issue nobody caught, a go-live plan that assumed nothing would go wrong, training that was left for later. Each has its own guide: data cleanup for the first, stakeholder rollout for the other two.
Validation deserves its own gate before any solver run. That gate is covered in checking timetable data before you generate.
What go-live readiness looks like
Ready means the data is cleaned, mapped, tested, and validated; staff are trained on the functions they own; the parallel run has ended without open differences; and the old files have a retirement date that everyone affected knows about.
If any of those is missing, the migration is not late. It is unfinished.
Questions planners ask about migrating from Excel
Why not cut over in one weekend?
A big-bang cutover is the fastest path to disruption: every data and training problem lands at once, live. A phased approach surfaces the same problems while the old process still works.
What does "validate" mean in a migration?
Prove the migrated data is fit to use: test imports pass, outputs match the old process during the parallel run, and the people who know the records have checked them.
When is the migration finished?
When the parallel run has ended, the old spreadsheets are retired for the migrated functions, and staff work in the new process without falling back. Retirement is the finish line, not go-live.