Before any export
Define the outcome, boundary and decision owners in writing.
Migration work becomes unsafe when nobody can say which workflows are launching, which records are authoritative or who may accept an exception. Resolve those questions before handling live school data.Treat implementation as a controlled school change, not a vendor-only technical task. The school owns its academic structure, record meanings, policy decisions and readiness approval. The implementation partner can map, configure, migrate and guide, but cannot decide which conflicting school record is correct without an authorised school owner.
Outcome
Describe the first useful school day.
Name the roles and workflows that must work at activation instead of using ‘all modules’ as an untestable objective.Boundary
Separate launch scope from later scope.
List what will be configured, migrated and tested now, what remains in the old process and what is explicitly deferred.Evidence
Define acceptance before migration.
Agree the counts, samples, relationships, calculations and role tasks that will prove readiness to the named approvers.| Decision or activity | School owner | Implementation partner | Acceptance evidence |
|---|---|---|---|
| Launch scope and sequence | Decision-maker confirms priorities and dependencies | Documents supported scope, assumptions and timing | Signed or otherwise approved written implementation plan |
| Source-record authority | Domain owner identifies the authoritative source and resolves conflicts | Inventories files, fields, formats and import constraints | Source-of-truth register with owner and cut-off date |
| Mapping and transformation | Domain owner approves meanings and permitted defaults | Prepares mapping rules and an exception log | Versioned field map with approved examples |
| Migration validation | Named approvers inspect records and workflows | Provides reconciliation results and corrects agreed defects | Completed checks with unresolved exceptions recorded |
| Activation and rollback | Decision-maker gives the go/no-go decision | Executes the agreed activation and support sequence | Dated gate, rollback trigger and support contacts |
Data-handling boundary
Do not use a public enquiry form as a migration route.
A demo normally needs fictional, redacted or formally approved sample data. Student records, family contact details, credentials, payment information and confidential school documents should move only through the approved implementation route and under the school’s applicable instructions and terms.
- A school decision-maker can approve scope, exceptions and activation.
- Each data domain has a named source owner and validation owner.
- The launch workflow, role, platform and dependency boundary is written down.
- Acceptance checks and evidence are agreed before the first import.
- The approved transfer route, access list and working location are recorded.
- A change-control rule explains what happens if source records change during migration.
Know what exists
Create a source-of-truth map before cleaning or transforming records.
A folder of spreadsheets is not a migration inventory. Record which source is authoritative, who owns it, when it was extracted, how records are identified and what must happen when two sources disagree.The National Digital Education Architecture (NDEAR) describes systems of record as the holders of primary data and emphasises interoperability, portability, permissions and consent. Use that as an architecture principle, not as a claim that a particular private ERP is automatically NDEAR-compliant.
Preservation rule
Keep one untouched extraction and work from a copy.
Record the extraction date, source system, file name, byte size or checksum where proportionate, and the person who supplied it. Transform a versioned working copy. Never ‘clean’ the only surviving source file in place.
| Data domain | Possible source | Authority questions | Migration decision |
|---|---|---|---|
| School structure | Academic setup sheet or current ERP | Which year, board, campus, class and section names are current? | Create first because people and workflows depend on it |
| Students and guardians | Admissions or student register | Which student ID is stable? Which guardian relationship and contact is authorised? | Map identifiers, names, status, class and relationships |
| Staff and roles | HR list plus role assignment records | Who is active, which role is required and who may approve access? | Import only the launch population and least necessary access |
| Fees and balances | Finance system, ledger or verified opening-balance sheet | What is the cut-off date, currency, due logic and approved opening balance? | Reconcile totals and student-level samples with Finance |
| Attendance | Daily or period registers | Which calendar, statuses, corrections and denominator apply? | Migrate only if the purpose and validation method are agreed |
| Assessments and results | Exam system or approved result sheets | Which exam, subject, maximum marks, grade scale and release state apply? | Validate structure, marks, grades and publication boundary |
| Documents and files | File store or document archive | Which files are required, current, authorised and supported? | Avoid bulk-copying obsolete, duplicated or out-of-scope material |
Resolve identity and relationship rules before rows are moved.
- Declare the stable school identifier for each student, employee, guardian, class, fee item and assessment where applicable.
- Separate a display name from a unique identifier; names alone are not reliable matching keys.
- Define how siblings, multiple guardians, changed contact details, transfers, withdrawals and duplicate records are handled.
- Record whether blank means unknown, not applicable, not collected or intentionally withheld.
- List reference values such as gender entries, relationship labels, statuses, fee heads and grade codes before mapping them.
- Choose one cut-off rule for live changes after extraction and identify who will capture the delta.
Make transformations reviewable
Clean, map and minimise data through explicit rules—not hidden spreadsheet edits.
Every transformation should be explainable to the school owner. Defaults, merges and exclusions need an approved rule because they can change identity, access, balances, attendance or results.Profile the source
Count rows, blank values, duplicate identifiers, invalid dates, unexpected codes and broken relationships before changing anything.
Define the target field
Record the target name, type, format, required state, allowed values, relationship and product constraint.
Write the transformation rule
State whether a value is copied, reformatted, translated, derived, split, merged, defaulted or excluded.
Route exceptions
Send ambiguous records to the named school owner. Do not choose a value merely to make an import pass.
Minimise the set
Remove fields and historical records that are unnecessary for the agreed launch purpose, subject to the school’s applicable obligations and decisions.
Version and approve
Give each mapping and prepared dataset a version, date, owner and status so the trial result can be reproduced.
| Source field | Target field | Rule | Exception and check |
|---|---|---|---|
| Student No. | Student identifier | Trim spaces; preserve leading zeroes; never derive from the name | Duplicate or missing values go to the student-record owner |
| DOB text | Date of birth | Convert an explicitly agreed source format to the target date format | Reject ambiguous dates rather than guessing day and month |
| Class + Section | Class relationship | Map only to an approved target class and section identifier | Unmapped combinations remain exceptions |
| Parent Mobile | Guardian contact | Normalise only after relationship and authorised-contact rules are confirmed | Do not create a guardian relationship from a phone number alone |
| Opening Due | Opening balance | Load the approved amount at the agreed finance cut-off date | Reconcile student samples and aggregate totals with Finance |
High-impact transformations
Never hide an assumption inside a default value.
A default class, guardian relationship, account role, attendance status, fee balance, result status or consent state can create a materially incorrect record. Leave the item unresolved and route it to the authorised owner when the source does not support the answer.
Personal-data handling needs a purpose and access review alongside the technical map. The Digital Personal Data Protection Act, 2023 and the notified Digital Personal Data Protection Rules, 2025 are primary sources for qualified review. The Rules have phased commencement, so verify the provisions and later notifications that apply at the relevant time instead of relying on a generic compliance badge.
Prove the migration
Run a representative trial and reconcile meaning, not just row counts.
A successful import message proves that a file was accepted. It does not prove that every intended record arrived once, relationships remained correct, balances agree or authorised roles can use the result.UDISE+ describes school data moving through system validation and designated review at multiple levels. A private ERP migration is a different process, but the lesson is useful: collection, automated checks, owner review and formal acceptance are separate controls. Do not collapse them into one upload step. Review the current UDISE+ context and official school-data instructions separately where they apply.
| Layer | Question | Evidence | Owner |
|---|---|---|---|
| Completeness | Did every intended in-scope record arrive? | Source, accepted, rejected and target counts by domain | Source owner plus implementation partner |
| Uniqueness | Did one source identity create one intended target identity? | Duplicate and collision report using stable identifiers | Student, staff or domain owner |
| Relationships | Are students, guardians, classes, subjects and accounts linked correctly? | Relationship counts plus edge-case samples | Academic and administrative owners |
| Financial integrity | Do opening balances and fee totals agree at the cut-off? | Aggregate reconciliation plus sampled student ledgers | Finance owner |
| Academic integrity | Do exam structure, marks, grades and release state remain correct? | Selected exam totals and learner-level samples | Academic or examination owner |
| Access and usability | Can each authorised role find and complete the agreed work? | Role-based test script with result and evidence | Role owner and access approver |
Acceptance boundary
A matching total row count is necessary evidence—not sufficient evidence.
The same total can hide dropped rows, duplicates, misassigned relationships or changed values. Reconcile by domain and status, then inspect representative normal, boundary and exception records with the people who understand them.
Build the test set deliberately.
- Include at least one normal record from every in-scope class, role or data domain.
- Include edge cases: siblings, multiple guardians, transfers, withdrawn learners, inactive staff, waived or partial fees, absent marks and changed sections where applicable.
- Test empty, invalid and unexpected source values to confirm that they become visible exceptions.
- Record expected and actual results; ‘looks fine’ is not a reproducible acceptance check.
- Classify defects by severity, owner, due date and activation impact.
- Repeat affected reconciliation after every corrective import and version the evidence.
Test the school day
Configure access, test real role journeys and train against the approved workflow.
Clean records can still produce a failed rollout when roles are wrong, staff do not know the new sequence or family access is activated before the school has checked what becomes visible.Administrator
Test control and exception paths.
Review configuration, account preparation, school-wide oversight, correction routes and the reports needed for activation.Teacher
Test the high-frequency classroom path.
Use a representative roster and device to complete the agreed attendance, academic or communication task.Parent and student
Validate authorised visibility before release.
Check the linked learner, released information, navigation and support route using fictional or approved sample context first.Support owner
Prepare the first response path.
Know who handles access questions, record corrections, workflow questions and vendor-requiring product issues after activation.| Role | Representative task | Pass evidence | Do not assume |
|---|---|---|---|
| Administrator | Find a learner, review relationships and inspect the agreed operational view | Correct school context, record, relationship and permission | One administrator account proves every permission is appropriate |
| Teacher | Open the right class and complete one agreed daily workflow | Correct roster, date or context, save result and review path | A desktop test proves the required mobile or low-connectivity experience |
| Parent or guardian | Open the authorised linked-child information included in launch scope | Correct child, released content and no unrelated learner exposure | Contact information alone proves an authorised relationship |
| Student | Access the authorised learner experience included in launch scope | Correct identity, class context, released content and support route | Student access should open before the school validates release settings |
Training evidence
Train the task, exception and support route together.
A role is not prepared merely because someone attended a presentation. Ask the participant to complete the real task, recognise one exception, explain what should not be entered or shared, and identify where to get help.
- Every launch role has a named owner and a representative test account.
- Access follows the least necessary role and inactive accounts are not enabled by default.
- Training uses the release, device and connectivity conditions expected at launch.
- Quick-reference material reflects the school’s approved workflow rather than a generic product tour.
- Participants know the school correction route and the enrolled-school product-support route.
- Parent or student release happens only after the school validates identity, relationships and visible information.
Activate deliberately
Use a go/no-go gate, preserve a rollback path and review the first live cycle.
The final migration is a controlled change window. Freeze or capture source changes, rerun the agreed reconciliation, obtain school approval and keep the old evidence available until the school’s retention and deletion decision is separately complete.Announce the change window
Tell affected roles what is changing, when the source cut-off applies, which tasks pause and where support will be available.
Control the final delta
Freeze the old system where feasible or capture every approved change after the extraction cut-off for a final delta update.
Run final migration and reconciliation
Use the approved versions, repeat the agreed counts and samples, and record every unresolved exception.
Take the go/no-go decision
The named school approver accepts, defers or rejects activation against the written gate—not against schedule pressure alone.
Support the first live cycle
Monitor the first attendance, fee, academic, communication or login cycle in scope and route issues to the correct owner.
Close with evidence
Record accepted exceptions, handover material, support contacts, source-system status and the later retention or deletion decision.
| Gate | Go when | No-go or rollback trigger |
|---|---|---|
| Data | Required counts, relationships, values and samples pass or have explicitly accepted exceptions | Material missing, duplicate, mislinked or unapproved records |
| Access | Required roles pass and unintended access is not observed | Wrong learner, school, role or unreleased information becomes visible |
| Workflow | Priority daily tasks pass in expected conditions | A critical task cannot be completed or corrected safely |
| People | Owners, trained users and support contacts are available | No authorised decision-maker or first-line support owner is available |
| Continuity | Final delta, rollback trigger and old-system access are understood | The school cannot reconstruct changes or return to the agreed safe state |
Deletion gate
Do not delete source records merely because activation succeeded.
Migration acceptance, operational retention and secure deletion are separate decisions. Preserve the agreed source and evidence until the school’s authorised owner confirms that reconciliation, statutory or board needs, contractual terms, dispute windows, backup treatment and any required export have been addressed.
Separate Schylva’s current public scope from school-specific confirmation.
Included in the standard launch service
- Standard onboarding
- Initial school configuration
- Initial data migration
- Staff training
- Ongoing product support
Confirmed in writing for the school
- Launch scope, roles and owners
- Source records, formats, method and migration rounds
- Mapping, validation and acceptance checks
- Training arrangement, timing and go-live plan
- Export, retention, deletion and enrolled-school support terms
Do not infer from the public website
- A universal implementation duration
- Unlimited or automatic migration of every historical record
- Public forms as an approved route for school records
- Published hosting, encryption, backup or recovery commitments
- A blanket certification or DPDP compliance guarantee
Schylva’s public implementation page states that initial migration is included and that the records, formats, method, rounds, validation steps and timing are confirmed in the school’s written implementation plan. Ongoing support is included, with the enrolled-school route provided during onboarding. Review the current implementation and onboarding scope and bring unresolved data, security, retention and exit terms into the written review.
- The final source cut-off and delta method are recorded.
- The exact prepared dataset and mapping versions are approved.
- Final reconciliation passes or every material exception has an authorised decision.
- Administrator, Teacher, Parent and Student paths are tested where included in launch scope.
- Training, first-line support and vendor escalation contacts are available.
- The go/no-go approver, rollback trigger and decision time are explicit.
- The first live cycle has a monitoring owner and review point.
- Source retention, export and deletion remain separate, recorded decisions.
Frequently asked questions
Clarify the decision and its boundaries.
Use these answers as a starting point, then verify the relevant source, rule and school process.How long does a school ERP implementation take?
There is no universal duration. School size, source quality, scope breadth, decision turnaround, configuration, migration rounds, validation, training and dependencies all affect timing. Schylva confirms school-specific timing and the go-live plan in the written implementation scope.
Which school data should be migrated first?
Begin with the foundation required by the agreed launch workflow: academic year and school structure, stable people identifiers, relationships, roles and accounts. Add fee, attendance, assessment, timetable, communication or document history only when its purpose, source, owner and validation method are defined.
Is a matching source and target row count enough to approve migration?
No. Matching totals can hide duplicates, omissions, changed values and broken relationships. Reconcile by domain and status, verify stable identifiers, inspect relationships and calculations, and test representative role workflows with named school owners.
Who should approve migrated school data?
The school should name approvers who understand each domain—for example, an administrative student-record owner, academic or examination owner, Finance owner and access approver—plus one decision-maker who owns the final activation decision. The implementation partner supplies evidence and resolves agreed technical defects.
When can the old ERP or source files be deleted?
Not merely when the new system goes live. Deletion should follow a separate authorised decision after migration reconciliation, operational acceptance, applicable retention or board requirements, contractual terms, backup treatment, dispute needs and required export or transition steps have been addressed.
Should live student data be used in a software demonstration?
Use fictional, redacted or formally approved sample data whenever possible. Do not submit student records, family contact details, credentials, payments or confidential school information through a public demo or quote form. Use only the approved implementation route for agreed live data handling.
Does Schylva include data migration and staff training?
Yes. Initial data migration and staff training are included in Schylva’s standard launch service. The school-specific written plan confirms the records, formats, method, migration rounds, validation, training arrangement, timing and owners.
What should happen when a trial migration finds a serious mismatch?
Stop the affected acceptance path, preserve the source and trial evidence, classify the issue, identify whether the source, mapping, transformation or target configuration caused it, obtain the authorised school decision where meaning is ambiguous, then repeat the affected migration and reconciliation. Do not waive a material mismatch only to preserve the launch date.
Primary sources and further reading
Read the official material behind the context.
Sources were reviewed when this checklist was updated on 30 August 2026. Always verify the current official version before relying on a rule or requirement.Ministry of Education
National Education Policy 2020 Primary policy source. It calls for education-technology interventions to be evaluated rigorously and transparently in relevant contexts before scaling.Ministry of Education — NDEAR
National Digital Education Architecture — Formal Complete Report Architecture context for systems of record, interoperability, portability, permissions and consent. It is not evidence that a particular ERP is NDEAR-compliant.Ministry of Education — NDEAR
Open Standards and Specifications for NDEAR Official standards context covering interoperability, consent, privacy, security, access control, portability and audit-related considerations.Ministry of Education
UDISE+ Official school-data platform describing school recording and designated validation. UDISE+ is not equated with a private school ERP or its migration process.Ministry of Education
UDISE+ Report 2024–25 — Existing Structure Official statistical report with school-level collection, validation and data-quality context. Verify the current reporting instructions separately.Ministry of Electronics and Information Technology
Digital Personal Data Protection Act, 2023 Primary statutory source for qualified review. This checklist does not decide applicability or provide a legal interpretation.Ministry of Electronics and Information Technology
Digital Personal Data Protection Rules, 2025 Official Gazette notification with phased commencement. Verify later notifications and obtain qualified advice where required.