A driving school software migration succeeds only when the new system can reproduce every open obligation and explain where it came from. Names and future appointments are necessary, but they are not enough. The migration must preserve relationships, lesson entitlements, payment and refund history, document evidence, permissions, communication context, and the links between those records. It must also prove that totals and business rules still reconcile after import.
For an owner, the practical test is simple: after cutover, can staff answer “What do we owe this student, what may they book, what has already happened, and why does the system believe that?” without opening the old platform?
“Survived” means more than appearing in a new database
A field can arrive while its meaning is lost. A balance of “4” might represent four unused lessons, four completed lessons, four hours, or four appointments. A PDF may transfer without its verification status or expiration date. A guardian may arrive as a contact but lose the relationship that controls what they may see or do.
A dependable migration preserves four things together:
- Value: the actual name, date, amount, status, note, or file.
- Relationship: which student, guardian, instructor, vehicle, order, appointment, or branch owns it.
- State: whether it is unused, reserved, completed, canceled, refunded, expired, verified, or pending.
- Provenance: the legacy identifier, source, timestamp, reviewer, and history needed to explain or audit it.
This is why a migration is not complete when row counts match. It is complete when the destination reproduces the school’s operating truth.
The seven data groups that must survive
| Data group | What must survive | Acceptance test |
|---|---|---|
| People and relationships | Students, guardians, staff, instructors, branches, contact details, account ownership, relationships, and stable legacy IDs | No duplicate people; every dependent, guardian, instructor, and branch relationship resolves correctly |
| Appointments and schedules | Past and future lessons, statuses, time zones, recurrence, instructor, vehicle, service, pickup and drop-off context, cancellations, no-shows, and notes | Future calendars match by day and resource; historical totals match by status |
| Orders and lesson entitlements | Packages, quantities purchased, quantities fulfilled, units reserved by future bookings, unused units, expirations, deposits, discounts, credits, and adjustments | Purchased = fulfilled + reserved + available + legitimately removed, for every student and order |
| Payments and refunds | Charges, payment status, processor references, invoices, payment requests, refunds, disputes, and open balances | Financial totals reconcile to the accounting source; no imported record creates a second charge or refund |
| Eligibility and evidence | Permit or license facts, document type, dates, expiration, verification state, source, reviewer, exceptions, and attached evidence | A transferred file does not become “verified” merely because it exists; readiness decisions still have their supporting facts |
| Communications and consent | Sender, recipient, channel, timestamps, delivery state, opt-outs, templates, notes, and relevant consent or mandate records | Staff can identify who received what, through which channel, and under which identity |
| Permissions and audit history | Roles, scopes, ownership, changes, actors, timestamps, previous values, source IDs, errors, and migration actions | Restricted users cannot see or change newly imported records outside their scope; administrators can trace the import |
A CSV can be valid and still create operational errors
Most migration failures are semantic, not syntactic. A clean spreadsheet can still hide four expensive problems.
1. Credits and appointments are counted twice
Suppose a student bought ten lessons, completed six, has one future lesson booked, and has three units still available. If the old system exports “four remaining” plus the future appointment, an importer that treats all four as freely bookable creates an extra obligation. The correct destination state is ten purchased, six fulfilled, one reserved, and three available.
2. Recurring or linked records become unrelated rows
An appointment date may import correctly while losing its recurrence, instructor, vehicle, pickup location, package allocation, or cancellation history. The calendar looks populated, but staff cannot safely edit the series or determine which entitlement funded the lesson.
3. A shared contact becomes the wrong identity
A parent’s email attached to a student record is not the same as a guardian account with a defined relationship and its own attributed actions. Combining people during migration can break account recovery, consent, communication history, and access control.
4. Saved payment credentials are treated like ordinary fields
Stored cards and bank authorizations should not move in a general customer CSV. Payment processors use controlled migration processes. Stripe, for example, documents explicit old-to-new customer ID mapping to prevent duplicates and separate rules for payment-method imports, defaults, wallet limitations, encryption, and authorization evidence. See Stripe’s guidance on mapping payment data and payment-method imports.
Use a six-stage migration instead of a one-time upload
- Define the cutover truth. Choose the systems that control student identity, schedules, money, evidence, and communications. Set a cutoff time and decide what becomes read-only.
- Inventory entities and relationships. Request a data dictionary, sample exports, attachment inventory, stable source IDs, status definitions, time zones, and known exceptions. Document what the destination cannot represent directly.
- Map meaning before columns. Translate each source status and balance into a destination state. Decide how to handle duplicates, missing owners, canceled appointments, expired documents, partial refunds, and package adjustments.
- Run a production-shaped dry run. Import a protected copy that includes ordinary records and edge cases: siblings sharing a guardian, a partially used package, a recurring lesson, a canceled appointment, an expired document, a partial refund, and a restricted staff user.
- Reconcile invariants. Compare counts, totals, relationships, and permissions—not just a handful of screenshots. AWS migration guidance likewise separates completeness from correctness, calls for logs and row counts, recommends checksums or hashes, and advises keeping old and new environments in parallel until accuracy and completeness agree. See the AWS migration testing guidance.
- Cut over with a rollback boundary. Record the final export, checksum, import version, start and finish times, exceptions, and approver. Keep the legacy system available in a controlled read-only state until the acceptance report is signed.
The acceptance report should test obligations, not just rows
Ask the implementation team for a written report that includes:
- source and destination counts for every entity type;
- duplicate, rejected, skipped, and transformed records;
- unresolved foreign keys or relationships;
- future lessons by date, instructor, vehicle, branch, and status;
- purchased, fulfilled, reserved, available, expired, refunded, and adjusted units;
- gross payments, refunds, disputes, open invoices, and balances by currency;
- documents by type, verification state, expiration state, and missing provenance;
- negative permission tests for staff, instructors, students, and guardians;
- a sample of before-and-after records, including every known edge case; and
- the rollback point and the person authorized to approve cutover.
Checksums help establish whether files changed in transit, but they cannot prove that a “remaining lesson” was interpreted correctly. Business invariants provide that second layer. NIST’s data-integrity guidance similarly emphasizes recovering data that is accurate and complete and using audit and reporting records to understand what happened. See the NIST data-integrity practice guide.
How RouteOS represents the records a migration must preserve
RouteOS is designed around connected operational records rather than a flat contact list. Its current architecture represents structured student information and evidence, guardian and dependent relationships, appointments and resources, package components and entitlements, orders, transactions and refunds, communication activity, scoped permissions, and audit events as distinct but linked data.
That matters during migration. An unused lesson can remain an entitlement instead of becoming an unexplained note. A future booking can reserve the correct unit instead of inflating availability. Evidence can retain its source, date, reviewer, and status instead of becoming a file that looks verified. Guardian actions can stay attributable to the guardian rather than appearing as the student.
Boundary: the current RouteOS implementation does not document a universal one-click importer that can correctly translate every legacy platform. Source-system mapping, payment-processor coordination, transformation rules, dry runs, exception handling, and reconciliation remain implementation work. The destination data model makes precise preservation possible; it does not remove the need to prove the migration.
If you are still comparing platforms, use the broader driving school software buyer’s guide. To see why progress data must remain operational rather than decorative, read what a student journey means in driving school software. For the identity side of the migration, review why guardians need separate accounts.
What to ask before signing a migration statement of work
Ask both vendors for the source export specification, destination data dictionary, field-and-status mapping, payment migration process, reconciliation report, exception policy, dry-run plan, cutover window, and rollback plan. Require legacy IDs to remain searchable or auditable. Then choose ten real records that represent your hardest cases and make their successful reconstruction a contractual acceptance test.
The decisive question is not “Can you import our students?” It is: Can the new system reproduce every current obligation, relationship, restriction, and piece of evidence—and show us how it proved the result?
Research reviewed September 5, 2026. Product behavior is described from the current RouteOS implementation evidence available for this article; migration scope depends on the source system and agreed implementation plan.