ARTICLE · Buyer Guides

School ERP को mid-session switch करें, साल बिगाड़े बिना

Schools मानते हैं कि software बदलने के लिए April का इंतज़ार ज़रूरी है। ऐसा नहीं है। Fees ledger को opening balance की तरह migrate करें, पुराने system को cut-off date पर freeze करें, session के बाक़ी invoices नए system से निकालें, और दो हफ़्ते दोनों parent apps चलाएँ। यहाँ 14-दिन का plan, data checklist, parents के लिए message और risks हैं।

Kanpur के 900-student school में October है। Fees counter अब भी उसी system पर चलता है जो school ने दो April पहले लिया था, receipts एक ही machine से print होती हैं, parent app पर 40% families हैं, और WhatsApp reminders accountant के अपने phone से जाते हैं। Principal जानती हैं कि school को switch करना चाहिए। Management का जवाब वही है जो हर school देता है: "Session ख़त्म होने के बाद। April में।" यानी उसी समस्या के छह महीने और, पुराने report-card format पर एक और annual examination, और — क्योंकि सब April कहते हैं — उन्हीं तीन हफ़्तों में migrate करने की कोशिश करते दूसरे schools की क़तार। School ERP switch करने के लिए April का इंतज़ार आदत है, नियम नहीं।

School ERP को mid-session switch करना safe क्यों है

School का साल एक लगातार चलता ledger नहीं है जो हिलाने पर टूट जाए। यह हर student के balance का set है, अभी निकलने वाले invoices का set है, और उन records का set है जो पहले ही हो चुके हैं। Balances को cut-off date पर opening balance की तरह migrate करें, उसी दिन पुराना system freeze करें, साल के बाक़ी invoices नए system से निकालें, और जो हो चुका है उसे history की तरह import करें। इसी क्रम में करने पर mid-session switch में लगभग दो हफ़्ते का calendar time, office का कुछ घंटों का ध्यान लगता है, और किसी parent को कोई gap नहीं दिखता।

Mid-session switch में असल में क्या चाहिए

हर सफल mid-year migration — Entab, Edunext, Fedena, Edumarshal, MyClassboard, Teachmint या spreadsheets के set से — इन्हीं पाँच कदमों पर टिकी है। एक छोड़ें तो साल सचमुच बिगड़ता है; पाँचों रखें तो नहीं।

  • Fees ledger को transactions की तरह नहीं, हर student के opening balance की तरह migrate करें। हर student के लिए cut-off date पर तीन संख्याएँ तय करें: इस session में कुल billed, कुल paid, और बाक़ी due (जहाँ concessions अलग हों वहाँ Fees head के हिसाब से)। नया system हर ledger उसी balance से शुरू करता है। पुरानी receipts audit trail की तरह पुराने system में रहती हैं।
  • पुराने system को एक ही cut-off date पर freeze करें। आमतौर पर महीने का आख़िरी दिन। उस तारीख़ के बाद पुराने system में कोई एक रुपया नहीं लेता और attendance नहीं लगाता; वह सिर्फ़ देखने के लिए खुला रहता है। एक दिन भी दोनों systems में payment लेना ही वह तरीक़ा है जिससे school के पास ऐसी receipt आ जाती है जिसे वह समझा नहीं पाता।
  • Session के बाक़ी invoices नए system से दोबारा निकालें। अगर आपकी Fees quarterly है और switch October में है, तो December और March की installments नए system में सही due dates, late Fees नियम और concessions के साथ नई बनती हैं। जो पहले भरा जा चुका है वह दोबारा नहीं बनता।
  • Attendance को शुरू की तारीख़ तक पीछे import करें। मौजूदा session की daily attendance 1 April से लाएँ ताकि annual percentage, 75% eligibility check और monthly register सब एक ही system से बनें। अगर पुराना system export नहीं दे सकता, तो class registers से महीना-दर-महीना import करें।
  • दो हफ़्ते दोनों parent apps चलाएँ। पुराना app या group चालू रखें, नए की घोषणा करें, और 14 दिन हर notice दोनों से भेजें। 15वें दिन पुराने channel पर एक message: "यह channel अब बंद है।"

Mid-year migration की data checklist

अपने office से यह तैयार करवाएँ, उसी क्रम में जिसमें ज़रूरत है। इसमें से ज़्यादातर पहले से मौजूद है; काम जाँचने का है, बनाने का नहीं।

  • Student master। Admission number, नाम, class और section, जन्मतिथि, gender, category, दोनों parents के नाम और mobile numbers, पता, photo। हर student की एक row, हर class की एक sheet — और उन students को हटाएँ जो जा चुके हैं पर कभी inactive नहीं किए गए।
  • मौजूदा session का Fees structure। Class के हिसाब से हर Fees head, installment pattern, due dates, late Fees नियम और route या room के हिसाब से transport या hostel Fees।
  • Paid और unpaid के साथ Fees ledger। Cut-off पर हर student का: billed, paid, due — head के हिसाब से। सौंपने से पहले इसे bank और cash book से मिलाएँ, क्योंकि migration हर वह गड़बड़ी सामने लाएगी जो पुराने system ने छिपाई थी।
  • Concessions और scholarships नियम की तरह। Sibling, staff ward, merit, RTE, management discretion — हर student का प्रकार और percentage या राशि, ताकि नया system इन्हें अगले invoices पर लगाए, one-off adjustment की तरह नहीं।
  • Transport assignments। हर student का route, stop, vehicle और Fees; जो routes अब नहीं चलते उन्हें retire करें।
  • Session की शुरुआत से attendance। 1 April से cut-off तक हर student की daily marking, या अगर बस इतना ही है तो महीने के totals।
  • पूरे हो चुके terms के exam marks। इस session में हो चुका हर assessment — subject के हिसाब से marks और grades — ताकि annual report card एक ही जगह से print हो।
  • Staff master और leave balances। अगर payroll भी move हो रहा है तो employees, designations, salary structure और अब तक ली गई leave।
  • Series numbers। आख़िरी receipt number, आख़िरी TC number और आख़िरी admission number, ताकि नया system sequence जारी रखे, दोबारा शुरू न करे।

School ERP को mid-session switch करने का 14-दिन का plan

नीचे का calendar मानता है कि extraction और cleaning नया vendor करता है — school को यही उम्मीद रखनी चाहिए। पूरे पखवाड़े में आपके office का कुल समय लगभग दो working days है, थोड़ा-थोड़ा बँटा हुआ।

  1. Day 1 — Cut-off date और go-live date तय करें। महीने का आख़िरी दिन cut-off; उसके बाद का पहला working day go-live। मौजूदा vendor को लिखित में बताएँ कि day 5 तक पूरा export चाहिए।
  2. Day 2 — Raw data सौंपें। Spreadsheets, module exports, अगर बस इतना ही है तो Fees register की photo। पहले साफ़ न करें; cleaning नए vendor का काम है और साफ़ की हुई sheets सुराग़ खो देती हैं।
  3. Day 3 — Fees ledger मिलाएँ। Accounts हर student का balance bank statement और cash book से मिलाता है। यह आपकी तरफ़ का सबसे लंबा काम है और वही जो ग़लतियाँ ढूँढता है।
  4. Day 4 — Concession नियम तय करें। हर discount नियम की तरह दोबारा लिखा जाए (प्रकार, राशि, कौन qualify करता है), principal के sign-off के साथ।
  5. Day 5 — साफ़ किया data review करें। Vendor judgement calls की छोटी list लौटाता है — कौन-सा duplicate sibling असली है, दो phone numbers में कौन-सा चालू है — और office एक घंटे में जवाब देता है।
  6. Day 6 — Staged school load करें। Students, parents, Fees structure, opening balances, transport और पूरे terms के marks ऐसे school में जाते हैं जिसमें आप login करके जाँच सकें, अभी कुछ live नहीं।
  7. Day 7 — Office verification। Accountant random 20 ledgers खोलकर पुराने system से मिलाता है। Class teachers अपनी class lists जाँचते हैं। जो ग़लत है वह वापस जाता है।
  8. Day 8 — Parents को पहला message भेजें। पुराने app या group से: तारीख़, क्या बदलेगा, क्या नहीं, और कौन-सा number save करना है। Script नीचे है।
  9. Day 9 — Office और class teachers को train करें। एक दिन on site: Fees counter, receipts, attendance, notices। Teachers को 30 मिनट चाहिए; Fees desk को पूरा दिन।
  10. Day 10 — बाक़ी invoices बनाएँ। अगली installment नए system में generate होती है, पाँच students पर हाथ से जाँची जाती है, फिर go-live पर release के लिए रोकी जाती है।
  11. Day 11 — Cut-off day। पुराने system में आख़िरी collections। दिन बंद करें, final balance report लें, और पुराने system को read-only कर दें।
  12. Day 12 — Go-live। महीने का पहला working day। Fees counter नए system में खुलता है; पहली receipt पुरानी number series जारी रखती है। पहले period से attendance नए app में।
  13. Day 13 — Parents को दूसरा message भेजें। दोनों channels से: नया app live है, receipts अब WhatsApp पर आएँगी, और online कैसे pay करें।
  14. Day 14 — Review और close। Receipts को cash से मिलाएँ, पक्का करें कि हर family को कम से कम एक message मिला, और जो मुट्ठी भर ग़लत numbers सामने आए उन्हें ठीक करें। 15वें दिन पुराना channel retire करें।

Parents को क्या बताएँ, और कब

Parents को software बदलने से एतराज़ नहीं होता। उन्हें surprise से होता है। दो messages — एक पहले, एक बाद में — surprise हटा देते हैं; शब्दों से ज़्यादा timing मायने रखती है, और यह कि message school के अपने number से आए।

Risks, और हर एक को कैसे cover करें

हर mid-session switch में वही मुट्ठी भर failure points होते हैं। इनमें से कोई भी इंतज़ार की वजह नहीं है; सब plan करने की वजह हैं।

  • Receipt-number की continuity। Auditors और income-tax department हर session में एक अटूट series की उम्मीद करते हैं। नए system का पहला receipt number पुराने के आख़िरी से एक ज़्यादा रखें, और changeover की तारीख़ cash book में दर्ज करें।
  • TC और admission-number series। वही नियम: series जारी रखें, दोबारा शुरू न करें। November में 1 number का transfer certificate अगले school में सवाल खड़े करता है।
  • Partial payments और transit में cheques। Cut-off date पर मिला पर बाद में clear हुआ cheque एक ही बार दर्ज होना चाहिए। Cut-off से पहले तय करें कि कौन-सा system उसका मालिक है — सबसे साफ़ जवाब नया system है, go-live पर cheque की तारीख़ के साथ entry।
  • Adjustment की तरह लगी concessions। पुराने systems अक्सर discount को नियम के बजाय one-time edit की तरह रखते हैं। अगर इसे नियम की तरह दोबारा नहीं लिखा गया, तो अगला invoice पूरी राशि bill करता है और parent principal को call करता है।
  • Late Fees नियम। पक्का करें कि नए system का late Fees नियम, grace days और rounding उसी overdue invoice पर वही संख्या दें जो पुराना देता था — तीन असली cases पर test करें।
  • RTE और scholarship students। इनके ledgers में due शून्य दिखता है पर reimbursement claim को billed राशि चाहिए। सिर्फ़ balance नहीं, billed आँकड़ा migrate करें।
  • पुराने system की access। कम से कम बाक़ी session और उसके बाद के audit तक read-only access रखें। अगर vendor सिर्फ़ export देगा, तो भुगतान बंद करने से पहले standard spreadsheet format में उस पर ज़ोर दें।

Mid-session switch की क़ीमत क्या है

India के ज़्यादातर school ERP vendors अलग implementation या data-migration charge quote करते हैं, और ज़्यादातर licence को session के बचे महीनों पर pro-rate करने के बजाय sign करने की तारीख़ से पूरे साल का bill करते हैं। इसलिए किसी और तुलना से पहले दो सवाल पूछें: migration का क्या ख़र्च है, और अगर मैं November में live जाऊँ तो क्या पूरे साल का पैसा दूँगा? जो vendor पहले का जवाब "₹0" और दूसरे का "सिर्फ़ जितने महीने इस्तेमाल करें" देता है, उसने वे दो ख़र्च हटा दिए जिनकी वजह से schools इंतज़ार करते हैं। यह भी पूछें कि मौजूदा vendor को बचे महीनों के लिए दिया पैसा क्या होगा; publicly, ज़्यादातर contracts refund नहीं करते — यह sunk cost है, ऐसे system को चलाते रहने की वजह नहीं जो रोज़ आपके office का समय खाता है।

Inkwelly कहाँ fit होता है

Inkwelly ठीक इसी move के लिए बना है। Entab, Edunext, Fedena, Edumarshal, MyClassboard, Teachmint या spreadsheets से migration ₹0 है, और process ऊपर के चार चरण हैं: हम extract करते हैं, हम clean करके judgement calls की छोटी list लेकर लौटते हैं, आप staged school जाँचते हैं, आप तारीख़ चुनते हैं। Go-live अगले working day हो सकता है। Mid-session switch के लिए हर student का opening balance सामान्य शुरुआत है, और बाक़ी installments Inkwelly में आपकी concessions को नियम की तरह लगाकर बनती हैं। Student data हर class की एक sheet में आता है — profile, class enrolment, पता और दोनों parents एक ही row में — पहले dry run में जाँचा हुआ, मौजूदा students कभी overwrite नहीं होते और import के दौरान families को कोई message नहीं जाता। Pricing ₹49–₹199 per student per year है जिसमें हर module शामिल है, और हर school 90-दिन के pilot से शुरू करता है जिसमें काम न बने तो pro-rata refund है। हर system से क्या migrate होता है यह dedicated guides बताती हैं: Entab से switch, Edunext से, Fedena से और Excel और registers से। Move का Fees वाला हिस्सा student fee management में है।

“April वह महीना है जब बाक़ी सब migrate करते हैं। एक cut-off date, opening balances और parents को दो messages — बस इतना ही चाहिए किसी भी महीने switch करने के लिए।”

एक हफ़्ते में फ़ैसला, दो में switch

अगर आपका office मौजूदा system पर रोज़ एक घंटा खो रहा है, तो छह महीने का इंतज़ार switch से ज़्यादा महँगा है। Cut-off date चुनें, नए vendor से दो cost सवाल पूछें, messy data सौंपें और उन्हें clean करने दें, staged school खुद जाँचें, और parents को दोनों messages समय पर भेजें। साल नहीं बिगड़ता। वह बस बेहतर ledger से आगे चलता है।

अगले April नहीं, इसी महीने switch करें

अपनी student list और Fees sheet जैसी है वैसी भेजें। हम आपके data पर staged school, हर student की opening balance report और go-live date लौटाएँगे — ₹0 migration cost पर।

Book a free demoMigration कैसे होती है

अक्सर पूछे गए सवाल

7 सवाल
Kya school academic year ke beech me ERP switch kar sakta hai?

हाँ। हर student का Fees ledger cut-off date पर opening balance (billed, paid, due) की तरह migrate करें, उसी दिन पुराना system freeze करें, बाक़ी installments नए system में निकालें, attendance और पूरे हो चुके terms के marks history की तरह import करें, और दो हफ़्ते दोनों parent channels चलाएँ। इसी क्रम में switch लगभग 14 दिन लेता है और annual reports एक ही system से print होती हैं।

School management software switch करने का सबसे अच्छा समय कब है?

किसी भी महीने का आख़िरी दिन cut-off, और उसके बाद का पहला working day go-live। Fees cycles के लिए term boundary सबसे साफ़ है, पर ज़रूरी नहीं। April हर vendor का सबसे व्यस्त महीना है, इसलिए October या January में switch करने वाले school को आमतौर पर ज़्यादा ध्यान और छोटी migration queue मिलती है।

Mid-year school ERP migrate करने के लिए कौन-सा data चाहिए?

दोनों parents के mobile numbers के साथ student master, मौजूदा session का Fees structure, bank से मिलाया हुआ हर student का Fees ledger (head के हिसाब से billed, paid, due), नियम की तरह concessions, transport assignments, 1 April से daily attendance, पूरे हो चुके terms के marks, payroll move हो रहा हो तो staff master, और आख़िरी receipt, TC और admission numbers ताकि series जारी रहें।

School ERP बदलते समय पहले से भरी Fees का क्या होता है?

वह audit trail की तरह पुराने system में रहती है और हर student के opening balance के हिस्से के रूप में नए में आती है। जो भरा जा चुका है वह दोबारा नहीं बनता। नया system सिर्फ़ बाक़ी due installments बनाता है, और पहली receipt पुरानी number series जारी रखती है ताकि session की receipts एक अटूट sequence रहें।

School software बदलने पर parents को कुछ करना होगा?

सिर्फ़ एक number save करना, और अगर school WhatsApp-based communication पर जा रहा है तो और कुछ नहीं। Cut-off से पहले एक message भेजें जिसमें तारीख़ और क्या बदलेगा बताया हो, और go-live के बाद एक जिसमें ledger और अगली due date की पुष्टि हो। पुराना app या group नए channel के साथ 14 दिन चालू रखें, फिर बंद करें।

Mid-year school ERP switch karne me zyada kharch hota hai kya?

हो सकता है, अगर नया vendor migration fee ले और sign करने की तारीख़ से पूरे साल का licence bill करे। Features की तुलना से पहले दोनों सवाल पूछें। कुछ vendors, जिनमें Inkwelly भी है, migration के लिए ₹0 लेते हैं और school को 90-दिन के pilot से शुरू करने देते हैं — इससे वे दो ख़र्च हट जाते हैं जिनकी वजह से schools April का इंतज़ार करते हैं।

Mid-session ERP migration में सबसे ज़्यादा क्या ग़लत होता है?

तीन चीज़ें: receipt numbers series जारी रखने के बजाय 1 से दोबारा शुरू होना, concessions नियम के बजाय one-off adjustment की तरह migrate होना जिससे अगला invoice पूरी राशि bill करता है, और दोनों systems में एक ही दिन payment लेना। हर एक को cut-off date, opening-balance sign-off और पहले invoice run की पाँच-student manual जाँच रोकती है।

आपको ये भी पसंद आ सकता है

5 लेख
लेखBest school management software in India (2026)लेखExcel & registers to a school ERP: migration guide (2026)लेखSchool ERP Implementation Time in India: Timeline (2026)लेखWhy School ERP Implementation Fails in India (2026)लेखMid-Year Admission School Process in India: A Guide (2026)

Inkwelly आपके स्कूल पर — खुद देखें

30 मिनट का डेमो। आपके मौजूदा ERP को आपके साथ खोलकर, कॉल पर ही आपका डेटा Inkwelly में लोड करते हैं। कॉल ख़त्म होते-होते एक तय तारीख़ का गो-लाइव प्लान आपके हाथ में।

डेमो बुक करेंWhatsApp पर बात करें
लेखकJharendra A VermaFounder, Inkwelly

Building Inkwelly — a modern school management platform for Indian schools across CBSE, ICSE, and state boards. Writes about school operations, board compliance, and admissions workflows.

School ERP mid-session में switch करें, साल बिगाड़े बिना (2026)