Migration
Moving from spreadsheets to flight school software: a two-week plan
Most software migrations drag on not for technical reasons but because the order is wrong. A day-by-day plan for a flight school to switch in two weeks.
- Published
- 3 min read
- 3 min read
- By
- Uçuş Okulu
Software migrations usually drag on not because of technical difficulty but because the work happens in the wrong order. Trying to import historic data first, going live before the team knows the system, and running two systems in parallel for months are the three most common mistakes.
The plan below rules all three out from the start.
Week one: definitions
Days 1–2 — Fleet and aerodromes
Enter the aircraft with their registrations, types and statuses. Mark which exercises each aircraft can be used for; this definition drives most of what follows. Add the aerodromes you use with their ICAO codes.
This step usually takes half a day, but its effect is large: leave it incomplete and the planning screen offers the wrong options.
Days 3–4 — Syllabus
Define the exercise groups and the exercises inside them: name, duration, flight or ground, repetition interval. Set the special row flags (progress check, revalidation, skill test) correctly — they decide which rows can be opened later.
The syllabus is the step that needs the most thought. Do not rush it; once it is right, you do not touch it again.
Day 5 — People and roles
Enter instructors and management staff and assign their roles. Do not enter students yet — it is not their turn.
While defining roles, answer “who should see what” together with the team. It can be corrected later, but getting it right first causes less friction.
Week two: usage
Days 6–7 — Active students
Enter only the students currently in training. Assign each one their syllabus group and post their existing progress: how many minutes against which exercise.
Do not enter graduates or long-absent students now. They are archive data and are not on the critical path.
Days 8–9 — Parallel run
Build the daily plan in both the spreadsheet and the system. The aim is not to test the software but to get the team used to the screen. Being slower for these two days is normal.
Note the differences. What usually surfaces is a missing exercise definition or a wrongly flagged aircraft eligibility, and both take minutes to fix.
Day 10 — Cut-over
From a chosen date, use the system only. Do not delete the spreadsheet, but do not open it. Extending the parallel period is the biggest enemy of a migration: with two records, nobody knows which one is right and the team trusts neither.
After: historic data
Import historic flight records after going live. That work holds nobody up and can run in the background. Attempting it first delays the migration by weeks.
What to watch in the first month
- Are actual times being entered? This is the most commonly skipped step. Reminders are needed until entering times after a flight becomes a habit.
- Are forms piling up? Check the pending forms list once a week.
- Are permissions right? In the first fortnight you will get “I cannot see this” requests; fix all of them at role level and avoid per-person exceptions.