School Data Migration: What to Bring, What to Leave [2026]

<h2>School Data Migration: The Decision That Decides Your ERP Project</h2> <p>Ask any Indian school administrator who just finished an ERP rollout what the hard part was, and nobody says "the software". They say the three weeks spent in a spreadsheet called <em>final_migration_v3_USE THIS.xlsx</em>, arguing about whether 200 students have their father's mobile number correct. That is <strong>school data migration</strong>, and it is where the majority of school ERP projects in India quietly lose weeks — or lose the trust of the office staff who have to use the thing afterwards.</p> <p>Search for guidance on this and you will find the same page repeated everywhere: a six-step vendor guide that says back up, clean, import, test, train, go live. All of that is correct and none of it is useful. The question those guides skip is the only question that actually decides the outcome — <strong>which of your spreadsheets deserve to come with you, and which are better left in a folder nobody opens</strong>.</p> <p>Get that call wrong and you get three familiar failures: imports that reject 15% of rows for missing dates, analytics that quietly lie because historical attendance was typed from a paper register, and a data-protection problem you created yourself by copying ten years of children's personal details into a new database. Get it right and go-live becomes a quiet Tuesday.</p> <p>This guide is the triage: what to bring, what to leave, how many rows you should expect to lose, and the two clauses that keep the migration from becoming a permanent dependency.</p> <h2>Why Every "How To Migrate" Guide Reads The Same</h2> <p>We looked at what actually ranks in India for this topic. It is almost entirely vendor-owned content: a Chanakya ERP blog post with six numbered steps, a "From Excel to ERP in 7 Days" playbook from another vendor, and a dozen product pages from ERP companies quoting ₹15,000 to ₹60,000 a year. All of them end with a contact form. <strong>Not one of them tells a school what to refuse.</strong> That is deliberate — telling a buyer "you don't need to move most of what you have" makes the project smaller and the quote smaller.</p> <p>So consider this the other half of that advice, and the part that actually decides whether <strong>school data migration</strong> ends in a working system. Bring the six tables below with complete honesty about every field. Leave the seven categories below behind on purpose, in writing, so your office team stops treating them as lost.</p> <h2>What to Bring: The Six Tables That Must Be Right</h2> <p>Migration only fails when a table arrives half-built. These six, in this order. Build them before you look at any software at all — a vendor cannot save you from a fee structure that exists only as last year's receipt book.</p> <table> <thead> <tr><th>#</th><th>Table</th><th>What "ready" actually means</th><th>The field people forget</th></tr> </thead> <tbody> <tr><td>1</td><td>Student master</td><td>One row per currently enrolled student. No merged cells, no "VIII" and "VIII-A" in two columns, no two rows for the same admission number.</td><td>Your own stable admission number — this becomes the primary key that every other table hangs off</td></tr> <tr><td>2</td><td>Fee structure &amp; heads</td><td>Fee heads with class-wise amounts and the instalment schedule, not the receipts. Term fees, admission fee, bus fee, lab fee, exam fee as separate heads.</td><td>The concession and scholarship rules — these drive the ERP's calculation engine and cannot be back-fitted later</td></tr> <tr><td>3</td><td>Outstanding dues snapshot</td><td>One dated line per student as at the cut-off date. A snapshot is auditable; a running ledger typed by hand is not.</td><td>The cut-off date itself, written on the file. Without it nobody can reconcile anything in March.</td></tr> <tr><td>4</td><td>Staff master</td><td>Staff code, name, role, subject, classes handled, one mobile, and UAN where the school has it. Bus drivers and helpers count.</td><td>Designation mapped to a fixed list — otherwise every staff record is free text and no report ever groups</td></tr> <tr><td>5</td><td>Transport master</td><td>Route, stop, vehicle number, capacity, driver mobile, fare per student.</td><td>Fare per stop, not per route. Indian bus fees almost always differ stop to stop.</td></tr> <tr><td>6</td><td>Class / section / subject / academic-year lookups</td><td>The small lookup tables built <em>before</em> any transaction data. Class names identical across all files.</td><td>Academic year with its start and end date — the single most commonly omitted field in Indian school spreadsheets</td></tr> </tbody> </table> <p>Notice what is not on that list: marks, attendance history, fee receipts, old admission forms, and question banks. All of it is either reconstructible or legally awkward. Notice too what schools most often forget — <strong>staff and transport are usually not in the spreadsheet at all</strong>. They live in someone's head or a paper file. That single gap is the most common reason a migration slips from three weeks to three months, because the vehicle list has to be rebuilt from scratch while the office waits.</p> <h2>What to Leave: Seven Files to Refuse on Purpose</h2> <p>This is the part nobody ranks for, and it is where your project either stays clean or quietly picks up a liability. Every item below should be an explicit, written decision — not an omission.</p> <table> <thead> <tr><th>Leave behind</th><th>Why it cannot come</th><th>What to do instead</th></tr> </thead> <tbody> <tr><td>Attendance registers older than 12 months</td><td>If the register was handwritten and someone typed it up later, the percentages are approximate. Import them and every attendance report is quietly wrong.</td><td>Start attendance analytics at go-live. Announce it as a feature — "analytics from day one" beats "we have eight years of messy data"</td></tr> <tr><td>Fee ledgers with a "Paid &#10003;" column and no transaction date</td><td>There is no way to reconcile an undated ledger. It cannot be audited and it becomes an internal-control finding.</td><td>Bring the dated dues snapshot (table 3) and start the transaction log fresh in the ERP</td></tr> <tr><td>Personal data of students who left more than ~2 years ago</td><td>India's <a href="https://www.meity.gov.in/data-protection-framework">Digital Personal Data Protection Act, 2023</a> is built on purpose limitation and storage limitation. Retaining a child's address and mobile long after the purpose ends is a live obligation, not a formality.</td><td>Keep only what a statutory record genuinely needs — TC, qualification, year of passing. Archive the rest, encrypted, with a deletion date.</td></tr> <tr><td>"Remarks", "Behaviour" and health columns</td><td>Observations about an individual child, written casually by a class teacher, are the highest-sensitivity thing in the file and the least likely to have been consented to any processing.</td><td>Delete the column entirely. If something is genuinely a health requirement, it belongs in a separate, access-controlled record with a named purpose</td></tr> <tr><td>Full 12-digit Aadhaar numbers</td><td><a href="https://uidai.gov.in/en/">UIDAI's guidance</a> is that entities needing only identity verification should not hold Aadhaar in readable form. A column of full numbers is exactly the copy that leaks from a shared drive.</td><td>Tokenise it, or keep the last four digits for identity check at admission and nothing more</td></tr> <tr><td>Staff salary slips, bank account numbers, medical details</td><td>Wrong file, wrong purpose, and payroll data is not student-migration data. Mixing them means your student migration file now contains staff financial records.</td><td>Separate payroll module or a separate file with its own access list and its own retention rule</td></tr> <tr><td>WhatsApp group contact lists as the "parent contact"</td><td>The number in a class group is whoever the class teacher added. The parent who signs the fee receipt may not be in that group at all.</td><td>Re-verify one primary mobile per family during admission-season data collection. It takes two evenings and removes a whole category of fee disputes.</td></tr> </tbody> </table> <p>The DPDP Rules, 2025 are the operational half of this — <a href="https://www.meity.gov.in/content/digital-personal-data-protection-rules-2025">MeitY's rules</a> set out how consent and notice actually work for schools handling children's data. Read them once before go-live rather than after a parent's lawyer emails you. If you want the wider picture of what a school's student data should look like, we covered it in <a href="/blog/post/data-security-in-schools-protecting-student-records-in-the-digital-age-2026/">protecting student records in the digital age</a>.</p> <h2>The Numbers That Decide Whether the Migration Worked</h2> <p>Before go-live, agree one number with your vendor: <strong>rows in, rows loaded, rows quarantined</strong>. And make it reconcile against a physical count of the students actually in your school on the cut-off date — roll call, not a spreadsheet. Anything less than 100% is a conversation, not a sign-off.</p> <p>Here is a worked example for a 900-student CBSE school, with every assumption labelled so you can swap in your own:</p> <table> <thead> <tr><th>Line</th><th>Example</th><th>Basis used — replace with yours</th></tr> </thead> <tbody> <tr><td>Rows in the student sheet</td><td>912</td><td>Spreadsheet as exported. Includes 12 students who left in June.</td></tr> <tr><td>Duplicate rows merged</td><td>−8</td><td>Same admission number typed twice during the April–June admission rush</td></tr> <tr><td>Left-school rows dropped</td><td>−12</td><td>Should have been dropped by the 2-year rule above</td></tr> <tr><td><strong>Active students loaded</strong></td><td><strong>892</strong></td><td>Against a physical roll count of 892. Match.</td></tr> <tr><td>Quarantined — missing parent mobile</td><td>27</td><td>Father's number blank, mother's number blank, guardian number blank</td></tr> <tr><td>Quarantined — missing date of birth</td><td>9</td><td>Blank or "as per records"</td></tr> <tr><td><strong>Total quarantined</strong></td><td><strong>36 (3.9% of loaded)</strong></td><td>Every one resolved by the office in days 1–5, then loaded</td></tr> </tbody> </table> <p>Two things to take from that table. First, <strong>under 5% rejection on a first pass is normal and fine</strong> — quarantine is a feature, because those 36 rows are precisely the ones that would have produced a wrong SMS, a wrong fee receipt and a wrong parent. Second, the reconciliation line is the acceptance test. If your loaded count does not equal the roll count, you have not migrated — you have imported a file.</p> <p>One more requirement that costs nothing: <strong>the load file must carry the UDISE+ code of your school and its school name exactly as registered on <a href="https://www.udiseplus.gov.in/">UDISE+</a></strong>. Your annual UDISE+ return asks for almost exactly the fields you are rebuilding — student strength by class, teacher count, infrastructure flags. If your migration file cannot answer that return without a second afternoon of manual work, it is not the right master data.</p> <h2>Write These Two Clauses Into the Quotation</h2> <p>Migration is the most commonly under-specified line in an Indian school ERP quotation. It usually appears as "implementation support", which is a promise of goodwill rather than a deliverable. Two sentences fix it:</p> <ol> <li><strong>Migration is a named deliverable with a date.</strong> "Migration of student, fee, staff and transport master data: complete and reconciled to the school's physical roll count by &lt;date&gt;. Two revision cycles included."</li> <li><strong>You get your data back, in a file you can read.</strong> "On termination or expiry, the vendor shall deliver every table loaded, as CSV and XLSX, within 15 days, at no charge. No exit fee."</li> </ol> <p>The second clause is the one that quietly protects you from lock-in, and it costs the vendor nothing — unless their data model is a one-way trap door, which is exactly what you want to know before signing. We wrote the full buyer-side clause library, including the per-student pricing traps and the AMC wording, in <a href="/blog/post/school-erp-rfp-india-the-buyers-guide-to-getting-the-best-price/">the School ERP RFP buyer's guide</a>. Read it before you go to tender, not after.</p> <h2>A Six-Week Plan That Doesn't Distract the School</h2> <p>Migration fails when the office stops answering the phone. So keep the classroom-side of the school running on paper or on the old spreadsheets until the new system is provably better, and never run both fee systems in parallel for more than one cycle.</p> <table> <thead> <tr><th>Week</th><th>What happens</th><th>Who</th><th>Done when</th></tr> </thead> <tbody> <tr><td>1</td><td>Build the six lookup and master tables. Count the students physically.</td><td>Office + one data owner</td><td>Student master exists with no empty required cells</td></tr> <tr><td>2</td><td>Take the written "leave" decisions. Delete the columns you are refusing.</td><td>Principal signs off</td><td>A one-page signed note exists saying what was left behind and why</td></tr> <tr><td>3</td><td>First load into a sandbox. Collect the rejection list.</td><td>Vendor + data owner</td><td>You have a rejection count and a reason for each</td></tr> <tr><td>4</td><td>Resolve quarantined rows. Verify fees: collect ₹1,000 from three parents in the new system and reconcile it the same day.</td><td>Cashier + accounts</td><td>Three live receipts, reconciled to the penny</td></tr> <tr><td>5</td><td>Rehearsal with real staff on real tasks. Attendance marking, a fee receipt, a TC request, an admission.</td><td>Everyone who will use it</td><td>No one needs the old spreadsheet to complete a task</td></tr> <tr><td>6</td><td>Go live Monday morning. Old spreadsheets frozen read-only. Run the annual UDISE+ return from the new system in week 6.</td><td>All</td><td>UDISE+ submitted without opening Excel</td></tr> </tbody> </table> <p>If your school is already convinced that spreadsheets are the bottleneck, the case is made in <a href="/blog/post/7-signs-your-school-has-outgrown-spreadsheets-and-needs-an-erp-2026/">7 signs your school has outgrown spreadsheets</a>. And the operational side — permissions, who sees what, training the non-technical half of your staff — is in our <a href="/blog/post/implementing-school-management-software-principals-checklist-2026/">principal's implementation checklist</a>.</p> <h2>The Mistakes Worth Naming</h2> <ul> <li><strong>Migrating first, configuring second.</strong> You end up forcing your old spreadsheet shape onto a system designed differently. Configure the classes, fee heads and designations first; map your data to those, not the reverse.</li> <li><strong>Trying to bring five years of history.</strong> Nobody reads it, it breaks the import, and it hands you a compliance problem. A dated snapshot plus a clean start beats a decade of noise.</li> <li><strong>Letting one person own the file.</strong> If the migration sheet lives only on the accounts clerk's laptop and she goes on leave in week 3, the project stops. Two copies, one shared drive, version numbers in the filename.</li> <li><strong>Skipping the physical roll count.</strong> This is the one free, unarguable accuracy check available to you, and most schools skip it.</li> <li><strong>Not writing down what you left behind.</strong> In March someone will ask where the 2019 attendance register went. A signed one-pager ends the argument.</li> </ul> <h2>Migration Is a Decision, Not a Data Transfer</h2> <p>The schools that get a clean ERP rollout in three weeks are not the ones with the tidiest spreadsheets. They are the ones that decided, early and in writing, what the new system is for — the current student, the current fee structure, the current staff list, the current bus routes — and were willing to leave everything else behind.</p> <p>Everything else in this project is plumbing. This is the decision.</p> <p>If you are planning a migration and want a second pair of eyes on your file before you commit, <a href="/saksham/">Saksham AI</a> includes data migration as part of onboarding, with the reconciliation count agreed up front — or <a href="/pricing/">see what it costs</a> for your student strength and compare it against the <a href="/blog/post/school-management-software-cost-in-india-the-2026-roi-guide/">five-year ROI model</a> first. Either way, book a demo and bring your spreadsheet. <a href="/#demo">Book a free demo</a>, and we will tell you honestly which parts of it you should not bother migrating.</p>