Moving off SIMS in a UAE School: What Actually Moves

A school management system built for the English school sector carries that sector’s assumptions in its bones — statutory returns, a term structure defined by national policy, and a long history of running on a server the school owned. SIMS is the most widely deployed example of that lineage, and a UAE school running it is usually running something that was excellent at a job it is no longer being asked to do.

This post is not about whether to move. It is about what actually moves when you do, because that is the part schools consistently underestimate — and it is a different question from the one covered in what goes wrong in a student data migration, which is about the process. This is about the data itself.

The columns that carry no meaning here

Start by finding out how much of your database exists to satisfy a framework you do not operate under. In a system shaped by a national statutory return, a substantial part of the student record exists to be counted: eligibility categories, funding-related flags, national identifiers, census-cycle fields.

In a UAE school those fields are usually empty, partially filled, or — worst — repurposed. A field labelled for one national concept, quietly reused by an administrator four years ago to store something else entirely, is the single most common cause of a migration producing data that imports cleanly and means nothing.

The audit that finds this is not technical. Print the field list, sit with the person who maintains each area, and ask one question per field: does anyone read this, and does it mean what it says?

Five data classes, in order of difficulty

1. Current students and contacts. Easiest, and still not trivial: the contact model is where duplicate parents and stale guardianship live. Reconcile a count before and after, not a sample.
2. Attendance. Moves cleanly as marks, but the mark meanings are local. A code that means one thing in your school may map to nothing in the new one. Agree the mapping in writing before anyone runs an import.
3. Admissions in flight. Difficult because it is a process, not a table. A half-completed application has a state, a next action and an owner. Most exports carry the fields and lose the state.
4. Assessment history. The hard one. Grades are only interpretable alongside the scale that produced them, and scales change. See below.
5. Pastoral and safeguarding notes. Technically simple, procedurally the most sensitive. Who may read them in the new system is a decision to make before the data moves, not after.

The three fields that always break

• Dates. Day-first and month-first formats produce a file that imports without a single error and silently relocates every birthday before the thirteenth of the month. Check a known record by hand, every time.
• Names. Transliterated Arabic names carry real variation, and the same person appears in three spellings across admissions, the register and the finance ledger. Deduplicating on exact match merges the wrong people and misses the right ones. Decide who adjudicates before the import, and expect that person to spend real hours on it.
• Historical grade scales. A grade from four years ago was produced under a scale that may no longer exist. Migrating the letter without the scale produces a record that looks complete and cannot be read. Either migrate the scale as data alongside it, or accept that the historical years are archive rather than analysis — but choose, and write the choice down.

The dry run is the deliverable

A migration that has been rehearsed once, end to end, on a full copy of real data, is a different project from one that has not. The rehearsal is where you learn the true duration, which is almost never the quoted one, and where the three problems above surface with weeks rather than hours to solve them.

Insist that the rehearsal ends the way the real one will: with the people who use each module opening the new system and looking for records they know by heart. A registrar who cannot find a specific family in ninety seconds has found something a reconciliation report will not.

What leaving on-premise actually changes

The operational differences are worth naming plainly, because they are the reason the move gets proposed and they are rarely the reason it is evaluated:

• Upgrades stop being an event that has to be scheduled around the school calendar and survived by one person who understands the server.
• Access from more than one campus stops being a networking project. For a group operating several sites, that alone can be the whole business case.
• Backup stops being something you believe is happening and becomes something with a stated recovery point you can ask a vendor to commit to in writing. Ask for the number.
• In exchange, you give up local control of the upgrade schedule. That is a genuine loss for a school with heavy customisation, and it belongs in the decision rather than in a surprise.

Where Scholyn fits, and where it does not

Scholyn is a UAE-first platform: multiple curricula on one campus, the Arabic and Islamic Studies stream inside the report card rather than beside it, and multi-site access as an assumption rather than a project. Migration support is scoped around the audit and the rehearsal described above rather than around an import button — the implementation approach sets out the sequence.

If your school runs deep local customisation you depend on and your hardest requirement is keeping control of your own upgrade schedule, staying on a system you host is a defensible answer and we will not argue you out of it. If your difficulty is that half your database describes a framework you do not operate under, and every campus you open is a networking problem, that is the situation this was built for.