An airline's crew scheduling and dispatch system is the one piece of software that can't be down on a Monday morning. Every pairing, every duty day, every flight release runs through it. Replacing it is the kind of project that gets scheduled for "next year" five years running.
Great North Airlines, a Transport Canada regulated scheduled airline flying regional jets and Dash 8 turboprops, did it in under 90 days. Project kickoff on 10 October 2025. First implementation session on 20 October. Live on 27 January 2026. Legacy system switched off after a week of checks in February.
Full disclosure on the calendar: the first implementation session was 20 October and the airline was live on 27 January, 99 days later. Sixteen of those days, 23 December to 7 January, were a holiday pause while the reporting and crew qualification pieces caught up. That leaves 83 days of implementation work. Under 90 days, counted from the first working session rather than the kickoff meeting ten days earlier.
What we owned
We ran the implementation end to end: one ForIT lead, one full-time developer and the airline's Director of Agile Programs, meeting the vendor's implementation team twice a week from 20 October.
The vendor brought the platform. We brought everything around it that makes a platform usable at an airline.
- Single sign-on. Every user signs in with their airline account. Pilots and flight attendants land in the right access group automatically based on their role. By June 2026 that was 89 production users.
- The data feed. Every 15 minutes the platform's flights and pairings copy into the airline's own reporting database. The vendor's flight feed stopped at 9,000 rows, so we worked around that too.
- The history. A year of records from the legacy system, archived and queryable next to the new data, so nobody lost the ability to answer a question about last February.
- The reports. Per diem, hours above minimum monthly guarantee, crew credit, delays: the reporting layer an airline's finance and crew planning teams actually run on. More than 20 of them, written against that database.
Parallel run, pause, go-live
From 2 December the airline ran both systems side by side, with a check-in every morning at 9:30. Pilot log-sheet training happened inside that window.
On 23 December the team made the call to pause. The critical reporting and the crew qualification records integration weren't ready, and going live without them over the holidays wasn't worth the risk. The go-live date moved to follow the work rather than the other way round.
Parallel-run issues were worked through in the second week of January. Production was cleared of test flights and crew schedules on 22 January, the go-live walkthrough ran the same day, the company-wide message went out on the 23rd, and the airline was live on the new platform on 27 January. The legacy system was shut off after a week of testing against it.
What went wrong
Here's the thing about hourly sync jobs: they fail quietly.
A few weeks after go-live, the flow that keeps the platform's crew list in step with the airline's directory was leaving departed crew active. One person's name didn't match their email, the loop skipped a step, and the deactivation half of the job silently stopped. Everyone showed up on every crew view until someone noticed.
We found it, fixed it and verified the fix on 19 February. We'd rather tell you that than pretend the cutover was flawless.
Results
- Under 90 days of implementation: first working session 20 October 2025, live 27 January 2026, holiday pause taken out. Legacy system off in February.
- One platform for crew scheduling, dispatch and compliance across both fleets.
- 89 production users on single sign-on by June 2026, grouped by role automatically.
- Flights and pairings in the airline's reporting database within 15 minutes, with a year of legacy history alongside.
- More than 20 custom reports the airline's finance and crew planning teams run on.
We don't have a before-and-after hours number for this one. The measurable win is the calendar, and the fact that the airline's own team was in the room twice a week instead of reading a status report.
The crew records work that came after, where AI reads each certificate and the chief pilot approves it, is its own case study.
If you're running a scheduled operation on a system nobody wants to touch, this is what the replacement looks like when one team owns it end to end. If you'd rather the vendor's project manager own it, that's a legitimate choice too. We'd just want to see the plan.
Benjamin Thomas
ForIT Team
