The 7-day go-live playbook for school ERP onboarding
Data migration, staff training, day-one fires, and the rollback plan — how Campus actually goes live in a week.
Most school ERP migrations run six to nine months. Ours run seven days. The difference isn't that we're moving fewer fields — Campus replaces fee, attendance, exam, transport, parent communication and admin in one cutover. The difference is that we treat go-live as a sequenced operations problem with a published runbook, not a project plan that everyone re-reads on Friday and re-interprets on Monday. Here is the actual seven-day shape.
Day 1 — Discovery and the migration spec
A two-person team (a customer success lead and a migration engineer) arrives on campus. The day's deliverables are unambiguous:
- A mapped inventory of every existing data source: legacy ERP exports, Excel sheets, the bursar's ledger book, the transport register, the admission file. We've seen up to 17 separate "systems of record" in a single school.
- A signed-off fee structure document, with every head, every concession rule and every GST treatment named.
- A signed-off academic structure: classes, sections, subjects, board, calendar, terms.
- The list of users to provision on day 5.
By 6 pm, we have a migration spec the school has read and signed. No surprise data discoveries on day 6 — every spreadsheet the office uses has been seen.
Day 2–3 — Data extraction and shaping
Most legacy ERPs in this market export to Excel or CSV. A handful export only via the school's licensed user account, which means a screen-scrape against the vendor's web app — we have a tool for this we won't link to publicly. Either way, the raw data gets shaped through a deterministic pipeline:
- Schema mapping — legacy column to Campus column, with type coercion.
- Reference resolution — every foreign key becomes a Campus ID.
- Validation — phone numbers normalised to E.164, dates to ISO 8601, GSTINs checksummed, fee balances reconciled to the bursar's books.
- Quarantine — anything that fails validation lands in a quarantine table that the migration engineer walks through with the school's office.
The quarantine pass is the single most important step. A school will swear their data is clean. The quarantine table will say "these 184 students have no parent contact and these 27 have a 9-digit phone number". We fix it together, on day 3.
Day 4 — Dry-run cutover
The full data lands in a staging tenant. The school's accountant logs in, looks at fee balances, and either matches them to the bursar's register or tells us where they don't. The principal logs in, looks at the attendance and class structure. The office staff log in and look up six students at random. Anything that fails this acceptance turns into a fix on the same evening and a re-import. Day 4 is the day we discover whatever we didn't discover on day 1.
Day 5 — Staff training
The training is structured by role, not by feature:
- Office staff — admission, fee receipt, parent contact updates. 90 minutes.
- Class teachers — attendance, marks entry, parent messaging. 60 minutes.
- Principal/headmaster — dashboards, approvals, board reports. 45 minutes.
- Accountant — fee reconciliation, refunds, GST exports. 60 minutes.
Every session ends with the staff member logging in on their own device and doing two real tasks. We've learned that training without the device-in-hand is theatre.
Day 6 — Soft launch
The school operates dual-system for one day. Yesterday's training is exercised on real work — receipts get cut in Campus, attendance is taken in Campus, but the legacy system also runs, and at end of day we reconcile the two. Discrepancies are almost always training gaps, not software bugs. We close them in real time.
Day 7 — Cutover
The legacy system goes read-only at end of day 6. Day 7 is Campus only. The day-one fires are predictable enough that we ship a checklist:
- A handful of parents call the office because the SMS they received about the new app came from a number they didn't recognise. The office tells them it's the school. This is the single most common day-one inbound.
- One or two staff members report "it's not working" — they've forgotten yesterday's password. We ship a password-reset SMS path that doesn't require IT.
- The accountant flags two or three legacy fee balances that look wrong. They're almost always rounding-mode differences with the legacy system. We document, we don't change the ledger.
By end of day 7, the customer-success lead leaves. The school has a Slack-shared support channel and a 24-hour response SLA. Most schools never escalate again.
The rollback plan
We carry an exported snapshot of the legacy data and a documented procedure to restore the school to legacy operation within 4 hours, retained for 30 days. We've used it twice in two years, both times because the school's leadership changed mid-onboarding and the new principal wanted to re-evaluate. Software didn't fail in either case. The plan existing is what made the school comfortable signing the contract.
A migration plan that can't roll back is a migration plan that won't ship. We sell Campus on the strength of the rollback we hope nobody uses.
If your school's current ERP is the reason your office stays till 8 pm, /campus is the product, and admin@airanexus.in books a discovery call.