Decide what is shared, governed and local.
Begin with the school group's real decision model. A central office may own identity standards, fee policy, audit requirements and reporting definitions while each campus owns daily attendance, family communication or admissions capacity. Write the rule for each domain before deciding which screen is centrally managed.
Shared standard
One definition, naming rule or control applies across the group and changes through an agreed approval process.
Central decision
A group role approves a high-impact action, with campus context and retained reasons.
Campus decision
An authorized local role acts within its institute without gaining visibility into another campus.
Group insight
Leadership receives only the approved group-level summary it needs, not unrestricted access to every campus’s detailed records.
Shared leadership must not become accidental cross-campus access.
Test access limits in the system itself and its stored data, not only through menus. A valid group role should receive only the explicitly approved view. Searches, files, downloads, automatic tasks and requests using a record’s identifier must stay within the intended institution unless an agreed cross-campus process authorises that exact action.
- Define the trusted source of campus membership and remove access when membership ends.
- If the system cannot confidently identify the institution, campus or user’s role, refuse the action rather than choosing a default campus.
- Test that unauthorised access is refused, using two sample campuses and similarly named people or records.
- Keep group reporting privacy-safe and purpose-limited; avoid copying detailed student records into a central sales or analytics surface.
- Record who exported what, for which campus, at what time and under which permission.
Map meaning before moving rows.
Different campuses often use the same label for different concepts, or different labels for the same concept. Build a list showing how each field in the old system matches a field in the new system for academic years, classes or batches, sections or timings, fee heads, statuses, identifiers and guardian relationships. Record rejected rows and reconciliation totals instead of silently repairing data during import.
- Inventory source systems, exports, owners, date ranges and data quality risks.
- Agree common definitions across the group while retaining the labels appropriate to each institution.
- Run a trial data transfer with fictional or protected test data and a repeatable procedure.
- Compare record counts, amounts and links with the source data; record rejected entries and where each imported record came from.
- Agree who manages the switch to the new system, when changes in the old system stop, how to return if needed and who corrects records after the switch.
Prove one repeatable campus pattern before scaling.
A pilot campus should be representative enough to expose the group's real variation, but bounded enough to support quickly. For each group of campuses, define the tasks, users, training, test or live data, support contacts, success measures, decision date and point to which operations can safely return. Do not add the next campus simply because the calendar says so.
Swipe for more columns →
| Wave gate | Minimum evidence | Stop condition |
|---|---|---|
| Ready | Owners, roles, configuration, data-transfer checks and training plan | Authority or source-data ownership is unresolved |
| Launch | Validated critical journeys, support route, monitoring and rollback | An important daily task has no responsible person or backup way of working |
| Stabilize | Open defects, adoption, exceptions, response times and corrected evidence | Teams rely on unofficial spreadsheets outside the agreed system or shared sign-in details |
| Repeat | Approved template, documented variations and a signed decision | The first campus still needs manual data repair to operate |
Ask for a decision-ready implementation pack.
- Shared, central and campus-owned decisions are documented by domain.
- Tests show that unauthorised actions are refused for staff roles, institutions and group reports.
- Keep the field-matching plan, data-transfer totals, unresolved entries and recovery plan.
- Each rollout wave has owners, support, success measures and a decision date.
- Terminology matches the institution type without changing the underlying control meaning.
- The next campus is approved from evidence, not assumed from the project plan.
Continue with the school ERP buyer guide for the broader selection framework, visit the resource centre, or review published pricing and total-cost assumptions before defining rollout scope.