Flight School Software Migration Checklist

A flight school software migration goes well when you do four things in order: export everything from the old system before you touch the new one, pick a cutover date right after month-end billing closes, run both systems side by side for a short and clearly defined period, and reconcile every student balance before anyone logs in somewhere new. Skip any one of them and the pain shows up at month end, usually as a student balance nobody can explain.

The checklist below is the order we'd do it in. It is written for the owner or office manager who still has to run the schedule, answer the phone, and dispatch airplanes while the move happens. Nothing here depends on which system you are leaving or which one you are moving to.

Before you sign: questions for the new vendor

Ask these in writing, and get the answers in writing:

• What can be imported, from which systems, and how? An import over an API, from a file export, and by hand are very different amounts of work. Get specifics for people, balances, training history, aircraft, and future reservations.
• Who does the import? You, the vendor, or both together. Who checks the result?
• What doesn't come over? Plan for those items now, not on cutover day.
• How do you get your data back out? You'll care about this again someday.
• Can you run a trial on your real schedule? A week of real bookings tells you more than any demo. Our guide on how to choose flight school scheduling software covers what to test.

Export everything first

Before you build anything in the new system, take a complete export from the old one, as of a specific date and time, and save it in a dated, read-only folder. Even items you don't plan to import belong in the archive.

People

• Students, renters, instructors, and staff, with contact details, emergency contacts, and categories or pricing groups
• Certificate numbers, ratings, and endorsements on file
• Medicals, IDs, passports, insurance, and other documents with their expiration dates

Money

• Every prepaid balance, as of the cutover timestamp
• Open invoices and unapplied credits
• Packages and block time, with hours remaining for each person
• Outstanding gift cards
• Your rate sheet: aircraft rates, instructor rates, fees, taxes, and any member or block pricing

Training

• Enrollments, lesson grades, stage check results, endorsements, and signed records for every active student
• Completed students' records too. If you are a Part 141 school, the records required by 14 CFR 141.101 must be kept at least 1 year after a student graduates, terminates, or transfers, and each instructor must keep their own records under 61.189 for at least 3 years. Those obligations don't end because you changed software.

Aircraft

• Current Hobbs and Tach for every airplane, read off the meters, not off the old system
• Inspection due dates and the times they are based on
• Open squawks, deferred items, and open work orders

The schedule

• Every reservation from the cutover date forward, including each recurring series and who it belongs to
• Instructor unavailability and standing student slots

Everything else

• Leads and their pipeline stage, with notes
• Signed policy documents and waivers
• TSA flight training security records, kept for as long as TSA requires; check the current program requirements with TSA
• The last 12 months of revenue and utilization reports, saved as PDFs, so you have a baseline to compare against

Saved payment methods

Saved cards don't come over in a spreadsheet. Card numbers can only move between payment processors through a secure processor-to-processor transfer, if the old and new processors can arrange one. Plan on asking students to save a card (or bank account) again, and give them a deadline.

Time the cutover around month-end billing

Never cut over in the last week of the month. If you do, one billing month is split across two systems, and month-end close turns into an investigation.

The cleaner plan: close the month in the old system, make sure every flight is invoiced and every payment recorded, and start the new system on the first flight of the next period. Also avoid:

• Your busiest season, if you can wait
• A week with several checkrides scheduled
• Any week the bookkeeper or the office manager is out
• Rate changes. Freeze prices until the migration is done, so you are not debugging two changes at once

Build and test before anyone else sees it

1. Aircraft first. Enter each airplane with its rates, current Hobbs and Tach, and inspection due dates. Compare the times against the meters in the airplane.
2. Activity types and rules. Dual, solo, rental, discovery flight, ground, maintenance, and any requirements attached to each.
3. People. Import them, then spot-check 10 records against the old system, including at least one instructor and one student with a complicated history.
4. Training history. Have the chief instructor review three students at different stages: one pre-solo, one near a checkride, one finished. Check grades, endorsements, and the lesson each one is on.
5. Opening balances. Enter each balance as of the cutover timestamp, with a note pointing to the old system's figure.
6. Future reservations. Re-create them and check every recurring series end to end.
7. A test flight on paper. Book a fake flight, check it out, complete it with meter readings, and invoice it. Then compare the invoice line by line with what the old system would have charged for the same flight.

Training history is often the most valuable thing to bring over and the hardest to rebuild by hand. Sky Schedule imports training history from your previous software, where supported, and the flight training records side keeps grades, endorsements, and student countersignatures with each lesson. Our page on how to switch flight school software to Sky Schedule explains what to expect.

Run both systems for a short, defined period

A parallel run is insurance, not a lifestyle. Set an end date before you start, and keep it short: a week or two.

• One schedule is live at any moment. On cutover day, bookings move to the new system. The old one becomes read-only for lookups. Two live schedules produce double bookings.
• Compare the first week's invoices. For each flight, check the new invoice against what the old system would have charged.
• Compare aircraft times daily. The new system's Hobbs and Tach should match the meters in the airplane every evening.
• Keep a running issue list. One shared document, with every problem, who owns it, and when it was fixed.

Reconcile balances before students log in

This is the step that protects your reputation. A student who sees the wrong balance in a new system assumes the new system is wrong, and then assumes you are.

• Each person's opening balance in the new system equals their balance in the old system at the cutover timestamp.
• The total of all prepaid balances matches the liability on your books.
• Package and block hours remaining match, person by person.
• Open invoices are either collected in the old system or re-created in the new one. Pick one approach, write it down, and apply it to everyone.
• Outstanding gift cards are listed and honored.

Have the owner and the bookkeeper sign off on a one-page reconciliation before any student invitation goes out. Prepaid balances and packages that carry over cleanly are what make flight school billing software trustworthy from day one.

Tell students and instructors

Instructors first. They get the questions on the ramp. Give them a walkthrough a week before students hear anything: how to see their schedule, check out and complete a flight, and log a lesson.

Students two weeks ahead. Tell them what changes (where they log in, how they book, how they pay) and what doesn't (their balance, their training progress, their instructor). Include the deadline to save a payment method.

On cutover day, send the login invitation and a short note asking each student to confirm their balance looks right. Questions now are cheaper than disputes at month end.

At the front desk, keep a one-page cheat sheet: where the common tasks live in the new system, and who to call when something looks wrong.

The first 30 days after a flight school software migration

• Daily: check yesterday's completed flights against yesterday's invoices.
• Week 1: compare aircraft times against the meters again, and clear the issue list.
• Week 2: walk through a full month-end with the bookkeeper in a test run, before the real one.
• Month end: close the first month in the new system. Compare revenue and hours flown with the same month last year.
• After that: cancel the old subscription only after the first month closes cleanly, and keep the export archive for as long as your records obligations require.

Your next step

Before you talk to any vendor, run a full export from your current system today and open every file. Note what's missing, what's messy, and what only exists in someone's head or a paper folder. That list is your real migration plan, and it is much better to find it now than on cutover day.