School ERP rollout across multiple campuses: a practical checklist for groups and dioceses

A group with five schools usually has five ways of doing everything. Five fee structures in five spreadsheets. Admission numbers that mean something different on each campus. A head office that collects its monthly figures by phone. One ERP across the group is meant to end that, and it can. But a rollout that treats every campus as identical produces a system that each school quietly works around, and a rollout that lets every campus configure its own produces five systems behind one login.

This guide is for the people who run school groups, trusts and dioceses in West Bengal, Assam and North East India, and for the principals who will live with the result. It covers the decisions that are specific to several campuses: what to standardise, who decides, how to agree on data, how to set permissions, and how to phase the work. For choosing an ERP in the first place, and for the detail of fee reconciliation and data migration, it points to our other school guides.

What to standardise, and what to leave to each campus

This is the central question, and one test settles most of it: will headquarters ever need to add this up, compare it across schools, or control it? If yes, standardise it. If it only has to work for one school's families and staff, leave it with the school.

Two points need care in this region. Groups often run schools under more than one board. Examination structure and report cards differ by board, so standardise within each board, not across the whole group. And schools may teach and communicate in different languages. Standardise the data and let each campus write to its parents in the language they read.

Governance: decide who decides

A multi-campus rollout fails on authority more often than on software. When two principals want different things, someone has to settle it, and that someone has to be named before the first disagreement.

• Keep a decisions register: what was decided, by whom, on what date. It prevents the same argument at every campus.
• Agree what headquarters decides and what a principal decides, and write it down. The software's permissions will be built from this.
• Decide how changes are approved after go-live. Who can add a fee head? Who can create a new role?
• Meet weekly during the rollout. Short, with the campus coordinators present.

Agree common data definitions before any migration

Consolidated reports are only as good as the definitions underneath them. If one campus counts a student who has not paid for three months as active and another does not, the group's enrolment figure is wrong on the day the system goes live, and nobody will know why.

Government identifiers belong in this discussion. Recognised schools already submit student-wise data every year to UDISE+, the Ministry of Education's school information system, which assigns each student a Permanent Education Number. APAAR IDs are generated against that number, with parental consent. Holding these identifiers on the student record makes annual reporting and transfers between schools easier. Ask any vendor exactly how they support UDISE+ reporting. An export in the required format and a live integration are different things, and you should know which one you are buying.

Student and fee data: one campus at a time

Our school ERP data migration checklist covers the method in detail: inventory, identifiers, field mapping, a trial run and a cutover plan. A group adds four problems of its own.

• The same child in two schools. Siblings share a guardian, and transferred students appear twice. Decide how duplicates are found and merged before importing the second campus.
• The same fee under different names. "Development fee" at one school is "annual charges" at another. Map both to the group's fee head, and keep the old name in the history.
• Opening balances. Each campus's arrears and advance payments must be agreed by its own accounts owner, in writing, before go-live.
• Reconciliation per campus. Check student counts by class and section, total outstanding dues, and one sample month of receipts against that school's own registers. A group total that looks right can hide two campuses that are wrong in opposite directions.

Roles and permissions across campuses

In a single school, most staff can be trusted to see most things. Across a group, access has to be designed. Three levels are usually enough: the group, the campus and the department.

• Campus staff see their own campus. Group finance and management see consolidated figures and can drill down.
• Set approval limits by role: who may grant a concession and up to what amount, who may cancel a receipt, who may change attendance after the day has closed.
• Give every user their own login. Shared accounts make the audit trail worthless.
• Decide who may export student lists, and log every export.
• Define how a transfer between campuses works, so the student's record moves once and is not re-entered.

Student records are children's personal data. India's Digital Personal Data Protection Act, 2023 treats anyone under 18 as a child, requires verifiable consent from a parent or guardian, and restricts tracking and behavioural monitoring of children, with a limited exemption for educational institutions. The Act's main obligations are being phased in, and on the government's published timeline they take effect in 2027. A rollout that records consent, limits exports and restricts access by role will be ready for it. This is general information, not legal advice.

Train by role, at each campus

One large session for all staff is the cheapest training to deliver and the least effective. People need to learn the part of the system they will use, on their own school's data, close to the day they start using it.

• Separate sessions for the front office, accounts, class teachers, the examination cell, the principal and headquarters.
• Train in the language staff work in, with the school's real classes and fee structure on screen.
• Leave a one-page guide for each role's daily tasks.
• Name one confident user per campus as the first person colleagues ask.
• Return after the first fee cycle. That is when the real questions appear.
• Add the training to induction, so staff who join next term are not taught by rumour.

Rollout phases

Going live everywhere on the same day multiplies every problem by the number of campuses. A phased rollout proves the design at one school and makes each later school faster.

1. 01Discovery and governanceVisit each campus. Record how admissions, fees, attendance and examinations work today, and where the schools differ. Appoint the roles above and open the decisions register.
2. 02Group configurationBuild the standards once: fee heads, concession categories, roles, approval limits, grading schemes for each board, and the reports headquarters needs. Record each campus-specific variation as a deliberate exception.
3. 03Pilot campusChoose a representative school, not the easiest and not the flagship, with a principal who wants it to work. Migrate and reconcile its data, train its staff, and run a full fee cycle.
4. 04Rollout in wavesBring the remaining campuses live a few at a time, each inheriting the group configuration. Fix what the pilot revealed before the first wave, not during it.
5. 05Stabilise and hand overStay close through the first group-wide fee cycle and the first examination. Then move to routine support, with the rollout owner still in place.

Timing matters as much as sequence. Avoid go-live during admissions, examinations or the week fees fall due. The start of a session or a term gives cleaner fee data than the middle of one. If the old system and the new one must run side by side, set a fixed end date for the old one. As a reference point, Techimpace's published plan for Academica One runs to about 16 weeks from discovery to the end of the phased rollout. Larger networks and untidy data take longer.

Campus readiness checklist

Before each campus goes live, the rollout owner and the principal should be able to tick every line. An unticked line is a reason to move the date.

Support and escalation

A teacher who cannot mark attendance at 8.30 in the morning should not need to know who the vendor is. Give every campus the same three-step route.

• First, the campus coordinator, who resolves how-to questions and password resets on the spot.
• Second, the group's rollout owner or help desk, for policy questions and anything that affects more than one campus.
• Third, the vendor, for defects and configuration changes, with agreed response times by severity.

Log every issue, even the ones solved in a minute. Reviewed weekly, the log shows which problems are training gaps, which are software defects and which are policies nobody decided. The remedy is different for each.

Adoption measures: is the system being used?

A system can be live at every campus and used properly at none. Measure use, not installation. Take a baseline in the first month and watch the direction. There is no universal benchmark for these figures.

Common mistakes in multi-campus rollouts

• Going live at every campus on the same day.
• Configuring each campus separately, so nothing can be consolidated.
• Letting headquarters design everything without the principals in the room.
• Migrating data that no one at the campus has reconciled.
• Training everyone together, once.
• Customising the software to preserve each school's habits instead of agreeing a common process.
• Dissolving the rollout team at go-live, before the first fee cycle has closed.

How Techimpace approaches a group rollout

Academica One is Techimpace's school ERP for chains, trusts, dioceses and educational groups. It provides a central dashboard across campuses, group-wide fee and finance consolidation, standardised admissions and student records, policy templates set once for the group, and transfers between campuses. Each school keeps its own fee amounts and day-to-day control inside the limits the group defines.

A discussion usually starts with how many campuses you have, which boards they follow, what each uses today and what headquarters cannot currently see. From that, Techimpace scopes configuration, migration, training and support for the group, and proposes a pilot campus. Confirm any specific integration or statutory report in the written proposal.