Skip to content
Operations

Opening a Second Campus in Another Emirate

A second campus is treated as a property and staffing project. It is also a data project nobody scoped, and the decisions are far cheaper before it opens than after.

7 min read
Group structure showing one central student identity above two campuses that keep classes, staffing and attendance local

Opening a second campus is usually treated as a property and staffing project, and it is also a data project that nobody scoped. The systems question looks trivial — add a site — and turns out to be four separate decisions that are much cheaper to make before the second campus opens than after.

1. One student directory, or two?

This is the decision everything else hangs off, and it is worth being precise about what is being asked. Not “one screen” — one identity space. Does a child exist once across the group, or once per campus?

Two directories feel easier for the first six months. Each campus runs its own admissions, its own numbering, its own registers, and nobody waits for anybody. Then a family enrols one child at each site, and the group discovers it has two records for one household, two contact sets that will drift apart, and no reliable way to count how many families it actually serves.

The identifier is where this bites first. If student numbers were assigned per campus and nobody wrote that down, every consolidated figure the group produces from that point is wrong in a way that is tedious to unpick later.

2. What is central, and what is local?

The opposite failure is a group so centralised that the second campus cannot function. If a registrar in the new site needs head office to add a class, approve a transfer or fix a typo, the queue becomes the reason people keep a private spreadsheet — and the private spreadsheet is the thing you opened a shared system to avoid.

The split that tends to hold:

  • Central: the student identity, the family record, group-wide reporting definitions, and anything where two campuses disagreeing would produce two truths.
  • Local: classes, timetable, staff assignment, daily attendance, and every routine correction. If a campus cannot fix its own register today, it will stop trying.

Worth deciding explicitly and writing down, because the default in most software is whichever the vendor happened to build, and you will inherit it silently.

3. Staff who work across both

Every two-campus group has them: a head of subject covering both sites, a counsellor on Tuesdays and Thursdays, a specialist teacher who commutes. They break single-site assumptions immediately.

The question to put to any system is narrow and revealing: can one person hold a role at two campuses with different permissions at each, and does their timetable resolve across both without being entered twice? Systems that model staff as belonging to a site will answer by suggesting two accounts, which works until someone has to reconcile them.

4. Reporting that is honest about the join

Group leadership will want the consolidated view, and it is the easiest thing to get subtly wrong. Two campuses can run different year-group structures, different assessment cycles, or different curricula entirely — the last of which is a whole problem on its own, covered in running two curricula on one campus.

A group attainment figure that averages across incompatible scales is not a summary, it is an error with a chart around it. What a board actually needs is the two campuses side by side, each on its own terms, with the comparison drawn where a comparison is legitimate and explicitly withheld where it is not.

The transfer between your own sites

Internal transfers are common in a group and are the case most systems handle worst. Done as a leaver-plus-joiner, the student arrives at the second campus as a new arrival: no history, no prior assessment, no inclusion record, and a file that starts from nothing.

Done properly, it is one record with a campus change recorded as an event on it. The history travels, the sibling link survives, and the receiving teacher can see what the previous one knew. That continuity is most of the reason a family stays inside the group when they move across the city.

What to ask before the second site opens

  • Can one child exist once across the group, with a campus attribute rather than a copy?
  • Can a campus registrar fix their own register today, without head office?
  • Can a member of staff hold two roles at two sites, with one timetable?
  • Can an internal transfer keep the history, in a way you have actually watched happen?
  • Does group reporting refuse to average things that should not be averaged?

Scholyn is built for exactly this shape, and it is a common one here — groups running campuses in Dubai, Abu Dhabi and Sharjah under one management team, sharing families and staff across sites.

The five questions above cost an afternoon before you open. Answered afterwards, they are a migration.

Frequently asked questions

Should the second campus get its own system or share the first one?

Share, in almost every case, but only if the shared system can keep the two campuses genuinely separate day to day. A single database with no local autonomy produces a queue at head office; two databases produce two versions of a family. The requirement is one directory with local control, not one screen.

What breaks first when a group grows to two sites?

The student identifier, usually. If numbering was per-campus and nobody said so, a sibling pair split across sites ends up as two unrelated records, and every consolidated count is wrong from that day forward.

How should a mid-year transfer between our own campuses work?

As a move, not a leave-and-rejoin. The student keeps one record and one history, with a campus change recorded as an event on it. Anything that exits and re-enrols loses the continuity that made the internal transfer attractive in the first place.

See it against your own school

A walkthrough configured to your curriculum, run by someone who can answer migration questions rather than defer them.

Book a demo