International-school guide to school management, ERP, and SIS

Start with the differences between campuses

International schools may share a brand while operating across countries, calendars, curricula, languages, currencies, and regulatory environments. Document which definitions and workflows are global and which must remain local.

Do not assume a single configuration is automatically simpler. A shared system needs a clear model for campus ownership, academic periods, local permissions, family communication, fees, staff, and reporting.

Map a cross-campus student journey

Trace admissions, enrollment, class placement, attendance, assessment, fees, documents, and family access for a student who changes campus or academic period. Record which identity persists, which data moves, who approves the change, and what each campus may see.

Test the edge case before the sales team presents a smooth local journey. A transfer, withdrawal, sibling relationship, guardian change, or calendar mismatch can expose the difference between a shared identity and a shared data model.

Separate global standards from local rules

Create a requirements register with global must-haves, local requirements, and configurable preferences. Include data protection, retention, transfers, support hours, incident response, payment providers, language, and exports. The school’s advisers must determine the legal requirements in each jurisdiction.

Use a decision record when a local need conflicts with a global standard. The record should name the risk, owner, evidence, scope, and review date rather than hiding the exception in a configuration note.

Evaluate vendor support and implementation

Ask who supports each campus, which team owns configuration, how updates are communicated, and how a critical issue escalates across time zones. Request a migration and training plan that names local owners as well as central governance.

Run the same workflow demonstrations for each representative campus. Score native behavior, configuration, integration, manual work, roadmap, and unknown separately. A global contract does not remove the need for local proof.

Design data and privacy controls

GOV.UK guidance on procuring educational technology recommends checking responsibilities, security measures, subprocessors, deletion or return, breach notification, and staff access control. Use the guidance as a question framework, then obtain jurisdiction-specific advice.

Data governance resources from the U.S. Department of Education emphasize the full lifecycle of education data, including acquisition, quality, access, sharing, security, disposal, and monitoring. Make the lifecycle explicit for each campus and transfer.

Roll out without flattening local reality

Choose a pilot campus or bounded workflow, define the evidence required, and rehearse with controlled sample data. Use the academic calendar for each campus and set a hold rule for critical failures. Expand only when local owners can operate the shared model safely.

Keep a local exception register and a global decision record. A local variation should have a reason, owner, evidence, and review date; otherwise it becomes an undocumented fork that increases support and migration risk.

Ask each campus to sign off on the part of the model it owns. Central approval cannot replace local validation of local data, calendar, family, or support requirements.

Plan how a local issue reaches central support and how a central change reaches local owners. Without that two-way route, campuses either wait too long or create private workarounds that weaken the shared model.

Review the local and global records together at each phase gate so a central improvement does not accidentally remove a necessary local safeguard.

Keep the transfer test in the release record for future campus onboarding.