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 a governed 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 the minimum approved aggregate view, not unrestricted operational records by default.
Shared leadership must not become accidental cross-campus access.
Test boundaries at the service and data layer, not only through menus. A valid group role should receive only the explicitly approved view. Campus searches, files, exports, background work and direct identifiers must stay inside the intended institute unless a documented cross-campus workflow authorizes the exact action.
- Define the trusted source of campus membership and remove access when membership ends.
- Reject ambiguous host, institute or role context instead of choosing a default campus.
- Test negative access with two realistic 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 source-to-target mapping 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 canonical terminology while preserving the tenant profile shown to users.
- Dry-run migration with synthetic or protected test data and a repeatable script.
- Reconcile counts, totals, relationships, rejected records and audit lineage.
- Approve cutover, freeze, rollback and post-cutover correction responsibilities.
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. Define the wave's workflows, users, training, data mode, support route, success measures, decision date and rollback point. Do not add the next campus simply because the calendar says so.
| Wave gate | Minimum evidence | Stop condition |
|---|---|---|
| Ready | Owners, roles, configuration, migration reconciliation and training plan | Authority or source-data ownership is unresolved |
| Launch | Validated critical journeys, support route, monitoring and rollback | A high-impact journey lacks an accountable fallback |
| Stabilize | Open defects, adoption, exceptions, response times and corrected evidence | Teams rely on shadow spreadsheets or shared credentials |
| 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.
- Role, institute and group-reporting boundaries have negative test evidence.
- Migration mappings, reconciliation totals, exceptions and rollback are retained.
- 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.