Migration
Changing timetabling system: what actually has to move
The data is the easy half. The things that break are the ones outside the software — the links people bookmarked, the feed another department depends on, and the habits of everybody who was already fluent in the old system.
Start by separating four different things
They are usually discussed as one project. They have almost nothing in common.
The structure — programmes, years, study routes, modules, groups and the hierarchy joining them. This is the skeleton, it is the part most likely to already exist in your student information system, and it is the part worth moving from there rather than from the old timetabling system.
The resources — rooms with real capacities and equipment, buildings, staff with their departments. Estates and HR usually hold better data than either timetabling system does, and a migration is a rare opportunity to correct it while somebody is paying attention.
This year's timetable — the actual placed lessons. Worth importing, and quick to import, but it is the least valuable of the four: next year's is generated, not copied.
Everything pointing at the old system — the links, the feeds, the screens, the integrations. This is the half that is forgotten in the plan and remembered in week one.
What transfers well
- Anything that is a list. Rooms, staff, modules, programmes, groups. Almost every system exports these, and where it does not, the database underneath it usually can.
- Constraints, once reclassified. They rarely transfer literally, and that is a feature: migration is the moment to sort the rules that must hold from the preferences you would like, which most institutions have never done. The distinction, with examples.
- The current timetable, as a starting point for the first term while people find their feet.
- Availability, if you have it in writing. Staff availability collected over years is real institutional knowledge and is worth carrying.
What does not, and should not
Last year's generated solution. It encodes last year's constraints, last year's cohort sizes and last year's rooms. Re-generating from the structure is faster than reconciling a year-old answer, and it is the first honest test of whether your constraints were ever written down properly.
Workarounds. Every long-lived timetable contains arrangements that exist because the old software could not do something: a module split into three because the system had no way to express a fortnightly pattern, a fictional room invented to hold a constraint. Carrying those across is carrying a limitation you are paying to leave behind. Find them, and ask what they were for.
Anybody's private spreadsheet. There is always one, it is usually load-bearing, and the migration is when it has to become part of the system or be deliberately retired.
The part that breaks outside the software
None of this is a data problem, and all of it is somebody's Monday morning.
- Bookmarked links. Students and staff have saved a URL to their own timetable, sometimes years ago. If the new one lives somewhere else, decide what the old address does — redirect it, or leave a page explaining where to go. Doing neither is the most common self-inflicted wound in a migration.
- Calendar subscriptions. Anybody who subscribed their phone to their timetable has a feed that will quietly stop updating rather than visibly fail. They will not notice until they miss something.
- Screens and signage. Foyer displays are usually configured once, by somebody who has since left, and point at a URL nobody has looked at in three years.
- Feeds into other systems. The VLE, the attendance system, the room-booking kiosk, the report somebody in Finance runs each quarter. Ask every department what they pull from the timetable, in writing, before the switch rather than after.
- The people who were fluent. Two or three colleagues were fast in the old system. For a term they will be slower, and they will be the ones asked to solve everything. Plan for that rather than being surprised by it.
An order that works
Inventory what points at the timetable
Before anything technical. Every link, feed, screen and integration, with a name against it. This list is the actual scope of the project and it is never as short as expected.
Move the structure, from the SIS where possible
Programmes, years, routes, modules, groups. If your student information system holds it, import from there rather than from the old timetabling system, and you have fixed the source of truth at the same time.
Move the resources, and correct them
Rooms and capacities from Estates, staff from HR. Expect to find rooms that no longer exist and capacities that changed when the furniture did.
Import the current timetable and publish it read-only
It gives everybody something familiar to look at, and it is the fastest way to find out what you got wrong: people recognise their own teaching.
Rebuild constraints as hard and soft
Not a translation exercise. Every rule gets classified deliberately, and the ones nobody can justify get dropped.
Generate in parallel, for one term, and compare
Run the new system alongside the old for a single term before committing. Compare on room utilisation and staff load, not on impression.
Switch the links last, and all at once
Redirects, feeds, screens and subscriptions on one day, from the inventory in step one.
How long it takes
Infrastructure is not the constraint. We set up hosting, import an institution's existing timetable and put its web pages in place in a few days — that part is routine, and it is what we are better at than anyone else in our market.
The rest is your data and your integrations. A first full cycle — structure, resources, availability, constraints, generation, verification, publication — typically runs a few weeks, and the single largest consumer is collecting staff availability rather than anything the software does. Subsequent years are dramatically shorter, because the structure carries forward and only the changes need attention.
The honest summary: the software is rarely what makes a migration long. Anybody who tells you otherwise is selling you the easy half.
Questions worth asking whoever you are evaluating
- Can you import our existing timetable, and what format do you need it in?
- What happens to the links our students have already saved?
- Is your integration interface documented publicly, so our developers can judge it before we commit? Ours is.
- Can we run both systems in parallel for a term?
- What does year two look like — how much of this work repeats?
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.