What Happens to Your Data When You Change School Management Systems?

Start by deciding what actually needs to move

Schools often have more data than they need on day one. A current student list, guardian links, classes and opening fee balances may be essential for operations, while years of old results or inactive records may require a separate migration stage.

Define the first operational scope before anyone starts copying files. That makes it easier to verify the important records and prevents a large historical archive from delaying the school's first usable setup.

Export from the old system before access becomes a problem

If the school is leaving another software provider, it should understand what can be exported and in which format. Useful exports may include students, guardians, classes, staff, balances, payments and historical results.

Do not wait until the final day of the old contract to discover that a needed report can only be viewed on screen. Schools should request usable copies of their records early enough to inspect them.

Mapping translates one system's columns into another

Two systems may store the same idea differently. One file may use “Student ID”, another “Admission No.”; one may keep first and last name in separate columns while another keeps the full name together.

Mapping is the process of deciding where each source field belongs in the new system. It should be reviewed before import, especially for identifiers, class names, guardian relationships, dates and financial balances.

Cleaning is different from rewriting the school's history

Migration commonly exposes duplicate rows, inconsistent phone formats, blank required fields, mixed date formats or class names that changed over time. Those issues should be identified rather than silently guessed.

If a record is unclear, the school should decide what is correct. A migration process should help reveal problems; it should not invent missing facts just to make a file import successfully.

Duplicates need an explicit rule

Duplicate students can appear because the same person was entered twice, because an old export contains multiple academic years, or because names match while admission numbers differ. The school needs a consistent way to determine whether records should be merged, kept separate or excluded.

Guardian duplicates can be more subtle. The same parent may be linked to several siblings, so the goal is not simply to delete repeated names. The relationship between the guardian and each student must remain correct.

Student and guardian relationships should be tested, not assumed

A clean student list is not enough if guardian links are wrong. Test families with one child, multiple siblings, different surnames and guardians who should no longer have active access.

After import, open sample student profiles and confirm that the right family records are attached to the right students before parent access is enabled.

Financial balances need a clear cut-off date

If outstanding fees are moving into the new system, agree the date at which the balance is being taken. Otherwise, a payment recorded in the old system during migration can cause the new opening balance to be wrong.

The school should be able to reconcile the total opening arrears in the new system with the approved source figure. Sample individual students as well as the overall total.

Historical results may deserve their own migration

Older results can be valuable, but they are often stored in a different structure from current records. Subjects may have changed, grading schemes may differ and some years may exist only as spreadsheets or PDFs.

If historical results are complex, separate them from the operational migration instead of forcing them into the first go-live. That allows the school to start using the new system while older academic data is handled carefully.

Run a test import before the final import

A test import gives the school a chance to see how real records appear before the migration is final. Check names, IDs, classes, guardians, dates, balances and sample reports.

The purpose is not only to prove that the file can be uploaded. It is to prove that the imported information is usable in the workflows that depend on it.

Go-live verification should use totals and real samples

After the final import, compare record counts with the approved source data and open representative records from different classes. If finance data moved, reconcile totals. If guardian links moved, test sibling families. If results moved, inspect several students across different periods.

Keep a record of what was migrated, what was intentionally excluded and any known items that still need attention.

Keep the original export and migration evidence

The school should retain an untouched copy of the source export, the cleaned working copy and the agreed migration result. Those files provide a reference if a question appears later.

Ask the new vendor how migration files are handled and when temporary copies are no longer needed. Data transfer should be treated as a controlled school process, not an informal exchange of spreadsheets.

Questions to ask a vendor before you migrate

SEAC's own process follows the same principle: agree the scope, review and validate the records, import into the correct school environment and verify before go-live. You can read the current SEAC data-migration page for the product-specific flow.