Nobody changes timetabling software because they are curious. They change because something has become intolerable — a licence renewal, a retiring colleague who was the only person who understood the old system, a school that has outgrown a desktop application, or a data protection officer asking questions nobody can answer.
And then they stop, because the timetable is the one system where a bad August is visible to every parent in September. The risk is not that the new software is worse. The risk is the switch itself.
This article is our attempt to remove that ambiguity: what transfers mechanically, what requires a human decision, and how to run a switch so that you always have a working plan.
What transfers cleanly
The good news is that the core of a timetable is far more standardised than the file formats suggest. Underneath every system are the same objects, and they map across almost one-to-one.
| Object | From aSc | From Untis | Notes |
|---|---|---|---|
| Subjects | Direct | Direct | Names, short codes, colours carry over |
| Teachers | Direct | Direct | Including short codes and subject qualifications |
| Classes | Direct | Direct | Grade and section structure preserved |
| Rooms & buildings | Direct | Direct | Room types may need mapping — see below |
| Periods & days | Direct | Direct | Bell times, breaks, lunch |
| Lesson cards | Direct | Direct | Class + subject + teacher + weekly hours |
| Teacher availability | Direct | Direct | Time-off grids transfer as blocks |
| The placed timetable | Direct | Direct | Imported as a starting scenario |
aSc exports XML, which is well documented and widely used as an integration path. Untis has its long established GPU/DIF interchange formats. Both are stable, both round-trip the objects above, and both are what our importer reads. Excel is also fine and is often the fastest route for a school that keeps a parallel spreadsheet anyway — most do.
What needs a decision
Three areas do not transfer mechanically, because the source systems encode them in ways that reflect a particular way of working rather than a universal fact about schools.
1. Groups, divisions and how a class splits
Every system models a split class differently — half-classes for languages, sets for Mathematics, boys and girls for sport, an elective band across three parallel classes. aSc represents these as divisions and seminar groups with stripes; Untis uses Schienen and course bands.
These structures import, but this is the point in a migration where it is worth pausing rather than copying. Many schools discover their group model accumulated over a decade of workarounds for what the old software could express — not what the school actually does. If a split exists only because the previous generator could not handle something, you may be carrying a scar rather than a requirement.
Our recommendation: import the groups as-is for the first parallel run, then review them once with the question "would we design it this way from scratch?"
2. Constraint weights and priorities
Hard constraints — no teacher in two places, room types, availability — transfer directly, because they are facts about the school.
Preferences are different. Untis expresses them through weighting sliders from 0 to 5 across thematic groups; aSc through its relations and generation parameters. These numbers are not portable, because they do not mean the same thing in a different engine. A weight of 4 in one system is not a weight of 4 in another; they enter different objective functions.
What is portable is the intent. "We care most about avoiding student gaps, then teacher gaps, then spreading subjects evenly" is a sentence that survives any migration. We start you from a profile that encodes a common ordering, and you calibrate over one or two runs.
3. Room types and special requirements
Room type taxonomies vary more than you would expect. One school has "Lab"; another distinguishes physics, chemistry and biology labs, each with different equipment. The import maps what it recognises and flags the rest rather than guessing — a lesson silently assigned to the wrong room category is the kind of error that surfaces in week two of term.
What does not come with you — and why we say so
Two things worth being direct about, because you will find out anyway.
Substitution planning. If your daily routine runs on aSc Substitutions or Untis Vertretungsplanung — the morning ritual of covering absent teachers — that workflow does not exist in Bildena today. It is on our roadmap, and it is the single most requested capability from schools in German-speaking Europe, where cover planning is a daily job and timetabling is an annual one. Until it ships, schools switching to us either keep their incumbent for substitutions or handle cover manually.
We would rather say this on a public blog than let you discover it in October.
Mobile apps for parents and students. aSc has EduPage; Untis has Untis Mobile. We publish to the browser and are building calendar subscriptions, which we think is a better fit — the timetable appears in the calendar app people already use, rather than a fifth school app on a parent's phone. But if your community lives inside a vendor app today, that is a real change of habit, not a like-for-like swap.
How to actually run the switch
The single most important principle: never make the new system load-bearing before it has proved itself on your data. A migration should never be a leap.
A calendar that works
- March–April — import and look. Bring in this year's data and this year's finished timetable. Nothing is at stake; you are checking that the objects arrived intact and that the numbers match.
- May — run the head-to-head. Generate a fresh timetable on the same data and compare it against the plan your current software produced. Same constraints, same school, two engines. Look at teacher gaps, student gaps, distribution quality and how long each took.
- June — plan next year in both. Build the new year's timetable in Bildena and in your incumbent. This is the real test, and the parallel run means the incumbent is still there if the answer is no.
- July — decide with evidence. By this point you are not choosing on a demo. You are choosing between two finished timetables for the same year.
- August–September — go live, keep the old licence. Do not cancel the incumbent in year one. The cost of one extra licence is trivial next to the cost of having no fallback.
Who should not switch
An honest list, because the wrong customer is worse than no customer.
- Schools where substitution planning is the daily backbone and there is no appetite to run two systems — wait for our substitution module rather than fighting a gap every morning.
- Public schools in German states with a Landeslizenz that makes Untis free. Competing with zero on price is not a serious argument; the case has to be that the generator, the transparency or the modern interface is worth real money. Sometimes it is. Often it is not, and we would rather you kept the free licence.
- Schools mid-crisis. If your timetable is on fire in August, that is not the moment to change engines. Fix this year, evaluate in spring.
Why we publish this
Every vendor's migration page promises a painless transition. In practice, the schools that switch well are the ones that knew in advance which three decisions they would have to make and which two capabilities they were giving up.
Timetabling is a small world with long memories. A school that switches on an accurate description of what they were getting stays for a decade. One that switches on a promise churns in a year and tells the neighbouring school why.
You can import aSc XML, Untis interchange files or Excel into a free Bildena workspace and run full generations free for a month, with every feature and no card needed. The point is to reach a finished timetable on your own data before any money changes hands.