To switch tutoring software without losing student data, freeze an export, clean and import a copy, then run both systems for 1 billing month; switch when invoices and teacher pay match. Keep each recurring class’s local time and IANA time-zone name so clock changes are calculated for each date.
What should “done” mean before you start?
A migration is done when the new system reproduces the records and decisions your academy depends on. You should be able to follow a student from family account to recurring class, invoice and teacher pay. Define those checks before importing anything, and name the person who will approve the switch. An accepted upload is not proof that billing is correct.
Write down your acceptance checks: family membership matches, rates retain their currency and class length, schedules display correctly, and outstanding amounts have a documented home. Include exceptions your spreadsheet currently handles through notes or manual adjustments.
Confirm what the software supports before cleaning records to fit it. A class format or billing rule that cannot be represented needs a decision before import. Use these questions to ask in a demo to check the actual workflow with your records.
Keep a route back to the spreadsheet until the checks pass. Assign responsibility for recording changes during migration so a new student or changed rate does not disappear between exports.
How do you clean students, families, rates and currencies?
Data cleaning should preserve meaning while removing ambiguity. Keep an untouched, read-only export, then work on a copy. Identify students separately from the people who pay their invoices. Resolve duplicate records, missing currencies and unclear rates before import. Keep a change log showing which original record became which destination record, especially when you merge names or family accounts.
Use a stable reference for each student. A name alone is a weak match when siblings share a surname or staff spell a name differently. Keep the original reference alongside the destination reference in your migration notes.
Separate the amount charged from the class duration. A rate without its duration leaves the importer guessing. Preserve currency codes rather than currency symbols, and distinguish unpaid invoice balances from money already received.
Treat blank fields as questions, not permission to guess. Ask the academy owner to resolve an unclear payer, rate or balance. Keep unresolved records out of the approved import until someone confirms the intended value.
How do you rebuild recurring classes with time zones?
Recurring classes need a weekday, local start time, duration, teacher, student and named time zone. Decide whose local time anchors the agreement with the family. Preserve that IANA zone with the recurring rule, then check how future occurrences appear for the teacher and academy admin. Copying a current UTC offset cannot preserve the agreement across changing clock rules.
IANA explains that its database changes when governments alter time rules. As of 21 October 2026, the release notes show why a migration cannot treat time-zone data as a permanent lookup table. Ask how the destination software receives updates.
Check dates around clock changes as well as the next scheduled class. Confirm the family’s intended local start and the teacher’s displayed time. The guide to UTC vs local time for recurring classes explains the distinction between a recurring local rule and an individual class instant.
Keep temporary changes separate from the recurring agreement. A rescheduled lesson should not silently replace the family’s usual weekday or start time in your cleaned records.
How do you import and spot-check the records?
An import needs an agreed field map and an exception list. Confirm which destination field receives each spreadsheet column, what happens to blank values, and how repeated imports identify existing records. Check connected records together after import. A student name appearing correctly says little about whether the family, schedule, rate and unpaid balance are attached to the right person.
Follow a family through the full workflow. Open each sibling’s record, inspect the billing account, check future lessons, and prepare an unsent invoice. Include records with different currencies or class lengths where your academy uses them.
Ask how historical invoices and open balances will be represented. If the destination cannot import a particular history, agree how staff will consult the archive. Do not assume every old column has a supported destination field.
For children’s records, follow your privacy policy and applicable law. As of 21 October 2026, the ICO’s guidance on children’s consent explains that the UK threshold is 13 when an information society service offered directly to children relies on consent. That is not a universal migration permission. This is general information, not legal or tax advice; check with an adviser in your country.
How do you run 1 billing month in parallel?
Parallel running should compare results without creating duplicate financial activity. Choose the system that will send real invoices and record actual receipts during the comparison month. Keep the new system’s comparison invoices unsent. Update both records when classes, rates or outcomes change, and keep a shared list of differences. Resolve the cause of each difference before approving the switch.
Compare invoice lines rather than totals alone. Matching totals can hide a missing sibling balanced by an incorrect rate. Check the student, class date, duration, currency, charge and remaining balance against the same underlying records.
Compare teacher pay separately from family charges. The amounts answer different questions. Check hourly rates, class lengths, recorded outcomes and any applicable fixed outcome rules. Document a policy difference rather than changing a rate merely to force a match.
Review prepaid amounts and later adjustments where relevant. Distinguish a real policy difference from a missing class outcome or duplicated payment. Keep the explanation with the discrepancy so the next admin can understand the decision.
How do you switch over and archive the spreadsheet?
Switch when the comparison is complete and unresolved differences have an agreed treatment. Announce where staff should enter new changes, stop editing the spreadsheet, and preserve the final export securely. Keep the archive available to authorized staff for historical questions. Decide access and retention according to your obligations rather than deleting records immediately after the new system starts working.
Before switching, follow these handover steps:
- Reconcile the final changes since the original export, including new students, payments and schedule edits.
- Confirm which invoices have already been sent and which balances remain outstanding.
- Show teachers and admins where to find classes, record outcomes and resolve exceptions.
- Confirm that families have the correct instructions and links for the new workflow.
- Mark the spreadsheet read-only and document who can retrieve archived records.
Keep the migration notes with the archive. Include the field map, approved exceptions and the point at which the new system became the working record.
What should you export and check before importing?
The migration checklist should cover relationships as well as individual fields. A student can import successfully while the family invoice or teacher rate remains wrong. Use the checklist to record what the destination needs and how you verified it. The fields below are migration requirements to discuss with your provider, rather than a claim that every system imports every object.
Export fields and checks
| Data object | Typical spreadsheet column(s) | Required in new system | Check before import |
|---|---|---|---|
| Students | Student reference, name, status | Distinct student record | Resolve duplicates and retain original reference. |
| Families/billing accounts (siblings) | Parent, payer email, family reference | Correct payer and student links | Confirm siblings belong to the intended account. |
| Currency per student | ISO currency code | Currency attached to student | Replace ambiguous symbols; flag mixed family currencies. |
| Rate per class length | Amount, currency, duration (minutes) | Rate with its duration | Confirm the amount describes the stated class length. |
| Recurring classes | Weekday, local start, duration (minutes), IANA zone, teacher | Student and teacher linked to local rule | Check future occurrences around clock changes. |
| Teachers and pay rates | Teacher reference, hourly rate (payroll currency/hour) | Teacher identity and hourly rate | Confirm rate basis without assuming currency conversion. |
| Open balances/unpaid invoices | Invoice reference, currency, amount outstanding | Agreed balance treatment | Exclude paid amounts and avoid duplicate debts. |
| Payment references | Receipt reference, date, amount, currency | Traceable payment history or archive | Match receipts to invoices without counting receipts again. |
| Consent records | Purpose, date, person giving consent | Accessible evidence or agreed archive | Preserve scope and evidence; investigate missing records. |
How Halqora handles this
Halqora is management software for online academies. Halqora schedules, bills and pays one-to-one classes; siblings can share a family invoice. Scheduling rules use each IANA time zone. Each student has a currency, and invoices are never converted. Billing runs create drafts for admin review and sending.
Halqora’s subject list is currently limited to 5 Quran and Islamic subjects. Check that scope and the fixed outcome rules against your records before moving. As of 21 October 2026, Halqora pricing and free onboarding include free onboarding, data import and a 14-day pilot. Allow time for cleaning and verification; the pilot does not replace the full billing-month comparison.
Sources
- IANA Time Zone Database overview, checked 21 October 2026
- IANA time-zone database release notes, checked 21 October 2026
- ICO guidance on information society services and children’s consent, checked 21 October 2026
