Excel to timetable software

How to clean school timetable data before import

The cleanup that decides whether your import passes: duplicates, formats, missing fields, and the field mappings that break migrations.

Juho Isola, Smootables founder

Clean the data before the import, not after it fails. The tasks are the same in nearly every migration: remove duplicates, standardise names, dates, and codes, fill missing fields, archive what the active year does not need, and migrate current records instead of the full archive.

The part that deserves the most suspicion is field mapping. Room structures that do not line up, staff codes that differ between systems, and duplicate curriculum entries break more timetable migrations than any other cause.

Cleanup is the first working step of a migration from Excel. Run it after you have mapped the risks in Excel timetable problems, and before checking timetable data for generation.

Key takeaways

  • Cleanup comes before import: duplicates, formats, missing fields, archived records.
  • Standardise names, dates, and codes; that is where matching breaks.
  • Migrate the active year's records and archive the rest.
  • Review the field mapping before the first test import; it is the most common break point.

The cleanup checklist

Work through this before the first test import. Coverage matters more than order; each item skipped shows up later as a mapping or validation failure.

  • Remove duplicate teacher, room, group, and curriculum records
  • Standardise names to one convention
  • Standardise date formats
  • Standardise staff, room, and course codes
  • Fill missing required fields
  • Archive records the active year does not use

Field mapping, the usual break point

Old and new structures rarely mean the same thing. Supplier-specific structures, inconsistent field definitions, rooms modelled differently on each side, staff codes that differ between systems, and duplicated curriculum entries are the recurring causes of failed timetable migrations.

When an import fails validation, treat the failure as a pointer back into this list. Guessing at the cause costs more time than re-checking the mapping.

Prepare the active year's data

The aim is an import that passes validation on the second attempt at the latest.

  1. List the records the active year actually needs: teachers, rooms, groups, study units.
  2. Archive everything outside that list.
  3. Deduplicate the active set.
  4. Standardise names, dates, and codes across it.
  5. Fill required fields where the source data supports it; flag the rest for the people who know the records.
  6. Review the field mapping against the target structure before the first test import.

How to do this in Smootables: preview and resolve before importing

The preview shows what the import will create, before it creates it.

Dirty data surfaces at two points in the Smootables import wizard: the preview and study-unit resolution.

  1. On the Mapping step, map only the columns you need. Set the rest to Don't import (skip column).
  2. Check the preview counts. A duplicate that survived cleanup shows up here as an extra teacher, group, or room about to be created.
  3. For findings listed under Validation errors, go back to the mapping step and fix the column mapping or the source data rather than importing around them.
  4. When one study unit name matches several qualifications, the wizard asks you to choose, and blocks with Resolve all study units before importing until each match is settled.
  5. Fix the source file and run the test import again until the preview is clean.

Current records first

Migrating the full archive multiplies every cleanup task and adds nothing the live process needs. Move the active year, keep the archive where it is, and revisit it only if a real need appears.

Cleanup on the school-data side continues in data preparation, which covers readiness for generation: teaching eligibility, availability, and hour limits rather than migration hygiene.

Questions planners ask about data cleanup

Should we clean in the old system or after import?

Before import. Data cleaned at the source imports cleanly everywhere; data fixed after import has to be fixed again on the next test run. The working order is clean, then map, then test.

Do we need to keep historical timetables?

Keep them, archive them, and leave them out of the migration. Migrating legacy data multiplies the cleanup and mapping work while adding records the active year never touches.

What counts as a duplicate?

The same real thing appearing as two records: one teacher under two spellings, one room under two codes, one course listed twice in the curriculum. Each duplicate becomes two separate objects after import unless it is merged first.

More guides on this topic

See how Smootables fits your school

Book a walkthrough and we will map Smootables to your planning, workload, and timetabling process.