Flight Operations Platform Migration

Challenge

The flight-ops system of record feeds everything downstream: crew tools, the passenger system, flight planning, maintenance, fuel, ACARS. Replacing it is open-heart surgery on a live airline. A full mesh of interdependent integrations had to be rebuilt against the new platform, validated with the business, and cut over with no interruption to daily operations.

Approach

• ▸Stood up an in-house ActiveMQ broker as the hub for every outbound message to the new platform and migrated the MuleSoft integration apps onto it; refactored ACARS forwarding from RabbitMQ to the new broker.
• ▸Built or hardened each integration by system: charter platform (multi-leg, IROPS, diversions, upsert, closed-on-OOOI), Navitaire passenger and bag counts, NavBlue flight-schedule sync over SOAP with diversion handling, Kronos flight messages, SSIM to AMDM, SlickOR feed, Ops Web remarks templates, and the Merlot crew-system CSV path.
• ▸Ran two onsite cycles with the vendor (a two-week UAT with the business in the room, then a design workshop) and a full mock run that produced the rollout plan, configuration naming conventions, and deployment guidelines.
• ▸Audited every passenger-sync integration for UTC/local date-crossover risk and drove datetime-anchored fixes across sync filters and validation logic.
• ▸Inventoried vendor endpoint, DNS, and external-network dependencies for release readiness; reconciled legacy UI roles to the new auth model one-to-one.
• ▸Owned the risk register: roughly 20 dependencies across cloud engineering, SRE, DevOps, InfoSec, and the vendor, each driven to closure before cutover.
• ▸Authored developer-ready tickets for every re-pointed integration: flight status sync, OOOI events, passenger counts, weight and balance, and crew-facing flight lookup.

Outcome

• 13 systems integrated against the new system of record with operations running throughout.
• Six vendor escalations resolved: an unannounced platform upgrade that dropped all inbound traffic, ACARS queue consumption, a diversion-event bug, missing message triggers, web-services authentication, and a SOAP interface enhancement.
• Date-crossover risk affecting roughly 94 flight legs a day identified and fixed at the sync-filter level before it reached production.
• Risk register empty for the four sprints before cutover; the legacy crew-view system reduced to view-only with the new platform as its flight-data source.