1
Analyse
We read your legacy system as it actually is — every table, every module, every count. You receive a classification of what will migrate, what is obsolete, and what needs a decision from you.
Switching from a legacy system
Switch without losing a record
The record of your institution — every student, every attendance day, every result — is not something to "re-enter later". Our assisted migration moves it whole: analysed first, rehearsed on a dry run, and proven record-for-record before you cut over.
Real migrations have carried multi-year histories — millions of attendance and marks records — with source and target reconciled to exact counts before cutover.
Five stages. No leaps of faith.
2
Preflight
Automated checks verify the target is clean, mappings are complete and prerequisites are met — before a single record moves. Failures block the run; nothing proceeds on hope.
3
Dry run
The full migration executes against a disposable copy. Counts, structures and spot-checks are compared record-for-record. You see the outcome of the real thing before the real thing.
4
Execute
The verified plan runs module by module in dependency order. Students, attendance, examinations, marks, staff — each module lands and reconciles before the next begins.
5
Prove parity
Source and target are compared exactly: the same number of students, the same attendance records, the same marks. Cutover happens only when the counts agree — and you see the proof.
The whole institution, module by module
Students & sessionsprofiles, guardians, class assignments across every session
Attendance archivesdaily and twice-daily records, years deep
Examinations & marksexams, marks, grades and computed results
Staff recordsemployees, designations and departments
Certificates & documentsissuance registers and record documents
Structure & mastersclasses, sections, subjects and reference data
Anything your legacy system holds that the platform does not model is flagged in the analysis for your decision — exported and archived, mapped, or consciously retired. Nothing disappears silently.
Run in parallel, cut over with proof
Most institutions do not switch in one weekend — and should not have to. The recommended pattern brings one function live first (attendance or fees), lets your staff build confidence on real work, and keeps the legacy system running untouched. When your team is ready, the historical archive migrates at a natural boundary — a session break — with the dry run and parity verification already done.
Your legacy system stays intact as the fallback until you choose to decommission it. The migration is staged and reversible until the final step; cutover is a decision you make with the proof in hand, not a bet.
Real migrations. Real operations.
A decade of records, moved whole
A school of about 1,800 students had run its legacy ERP for years — attendance marked twice daily, every exam on record. The full history was analysed, dry-run rehearsed and migrated module by module, then reconciled against the source system to exact counts before cutover. The department structure was consolidated in the same move; nothing was re-typed and nothing was lost.
- 1.1M+
- daily attendance records migrated
- 2.2M+
- twice-daily marks carried
- 1,250+
- exam definitions preserved
- Exact
- source↔target parity at cutover
The whole institution, running live
A multi-session school operates its full academic cycle on the platform: enrolment across nineteen classes, attendance governance with day locking, and the complete examination cycle from marks entry to published marksheets — with every computed result traceable to the engine that produced it.
- 6,700+
- student records across sessions
- 1.3M+
- marks recorded and computed
- 195K+
- marksheet mappings maintained
- 74
- sections in daily operation
Institutions are unnamed by their choice — every figure above comes from verified runs.
Migration — asked and answered
How much history can we bring?
As much as your legacy system holds — students across sessions, attendance archives, examination results, staff records. Migrations routinely carry multi-year histories measured in millions of records; volume is a planning input, not a limit.
What happens to data your platform does not model?
The analysis classifies every legacy table. Anything without a home is flagged for your decision — export and archive, map to a custom field, or consciously retire. Nothing disappears silently.
How long does a migration take?
Analysis and dry runs take days, not months, and run without touching your live operations. The final cutover is scheduled at a natural boundary — a weekend or session break — after parity has already been proven.
Can we keep running the old system during the transition?
Yes — that is the recommended pattern. Bring one function live on ez.school first (attendance or fees), run in parallel while your team gains confidence, then migrate the historical archive at cutover.
What if something is wrong after cutover?
Parity verification exists precisely so wrongness is caught before cutover, on the dry run. The staged process is reversible until the final step, and your legacy system remains intact as the fallback until you decommission it.
Bring your history with you
Tell us what you run today — we'll map the path from analysis to proven cutover.