Migration plan for school management, ERP, and SIS

Set the migration boundary

Write down what the first phase will migrate, what will be archived, what will remain in the old process temporarily, and what is explicitly out of scope. Include the school type, campuses, academic period, departments, and family-facing workflows affected.

A boundary prevents the project from treating every historical record as equally urgent. It also gives owners a clear list to validate instead of a vague instruction to make the new system complete.

Put the boundary in the project decision record and repeat it in vendor and staff communications. A scope item that is “temporarily out” still needs an owner and a safe interim process until the next phase is approved.

Map entities and ownership

Create a mapping for students, guardians, relationships, staff, classes, subjects, dates, fees, payments, attendance, assessments, documents, and communications as relevant to phase one. For each entity, record source, destination, transformation, owner, required fields, and validation output.

Do not silently merge values that look similar. A name, contact, or identifier may differ for a valid reason. Define matching and correction rules with the people responsible for the record.

Run a profiling and cleansing pass

Measure duplicates, missing values, invalid formats, stale contacts, conflicting assignments, and records without an accountable owner. Classify each issue as correct, map, archive, investigate, or accept with a documented risk.

Keep the source unchanged while the team decides what to do. Preserve a version of the mapping and an exception register so a later import can be compared with the earlier decision.

Rehearse with controlled data

Use a small dataset that includes normal records and edge cases. Rehearse import, correction, permissions, reports, exports, receipts, attendance, assessment publishing, and family visibility. Record expected and actual outcomes with an owner for every discrepancy.

Repeat the rehearsal after mapping or configuration changes. A first successful import proves only that one file was accepted; it does not prove that the school’s workflow or definitions are correct.

Reconcile outputs

Compare source and destination counts, identity matches, class membership, staff assignment, fee balances, attendance, assessments, reports, and family-visible information. The exact outputs depend on scope, but every important downstream action needs a validation method.

Require the operational owner to sign off. Technical completeness and operational correctness are different decisions. The person who prepares a report or supports a family is often best placed to see an error that a file comparison misses.

Keep the reconciliation result with the mapping version that produced it. If a rule changes, the team should be able to tell which outputs need to be tested again rather than assuming an earlier sign-off still applies.

Plan permissions and support

Create role scenarios for teachers, academic leaders, finance, administrators, IT, and families. Test view, edit, approve, publish, export, role change, and leaver behavior. Define who handles access questions and how a mistaken permission is corrected.

Plan the first support period around the academic calendar. A go-live during examinations, fee collection, admissions deadlines, or low staffing needs a different hold rule and escalation plan than a quiet planning window.

Choose the go-live decision

Set pass conditions for identity, access, payment, assessment, report, family, and support scenarios. Define which failures block launch, which can be accepted with an owner, and when the decision is revisited. If a critical test fails, hold or narrow the release instead of hiding it in a status meeting.