CM

Airline Operations Technology

Claudio Mirabal

Technical Product Owner · Airline Operations Systems

I own the integration layer between an airline's flight-operations systems and the vendors that run them. Recent work: the integration program for a flight-ops platform migration with a live-operations cutover, a charter-operations platform taken from contract to production, an in-house schedule-validation product, and an FAA compliance program delivered on its date. I write the spec, run the UAT, and ship the release.

See the programsEmailGitHub
13
Systems integrated
under one migration program
25+
Production releases
across 30 sprints
80
Users trained
on the new charter platform
6
Vendor escalations
driven to resolution

01 · Programs

Programs I have led

Each one reads Challenge, Approach, Outcome. Click a program to open the detail, or open it as a standalone case study to share.

Flagship

Apr 2025 – present · go-live Nov 2026·Program and product lead for the integration layer

Leading the integration layer of an airline's move from in-house flight movement systems to CAE Movement Manager: 13 integrations, a new message-broker architecture, two onsite UAT cycles, and a cutover that happens while the airline keeps flying.

  • CAE Movement Manager
  • MuleSoft / CloudHub 2.0
  • ActiveMQ
  • Navitaire
  • NavBlue NFP
  • ACARS
  • Kronos
  • Merlot
  • AirlineChoice
  • SlickOR
  • CAE AMDM

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.
Open as a standalone case study

Flagship

2025 – 2026·Product owner end to end: analysis, vendor selection, contract, procurement, requirements, UAT, training, release

Moved 100% of an airline's charter operations off legacy in-house tooling onto AirlineChoice, under budget, with the flight-ops sync built in MuleSoft. Then led the engagement that secured a merger partner's agreement to beta the platform for its own charter operation.

  • AirlineChoice
  • MuleSoft / CloudHub 2.0
  • Legacy FMM
  • CAE Movement Manager
  • NavBlue NFP
  • Navitaire
  • Secure Flight / APIS / CBP

Challenge

Charter operations ran on legacy in-house tooling: manifests, station operations, TSA and CBP compliance touchpoints, no international capability, and heavy manual entry. The replacement had to be a vendor platform selected and contracted from scratch, and it had to stay in lockstep with the flight-ops system of record in both directions while that system was itself being migrated.

Approach

  • Ran product analysis, vendor selection, contract negotiation, and procurement; then owned development, beta, and UAT through release.
  • Trained 80 users and built the company computer-based training modules.
  • Designed the flight-ops sync in MuleSoft: flight creation and OOOI times, booked passengers at T-24h and T-3h, actual passengers on departure, flight status closed on OOOI receipt, reposition and IROP handling, with full MUnit coverage.
  • Diagnosed a duplicate-segment defect at its root: charter flights lacked the reservation-level match key the sync relied on. Designed a fallback match key at the flight-ops level that turned erroneous inserts into correct updates.
  • Released in stages: dark release and UAT in January 2026, semi-dark in February as a secondary path for agents, passenger counts back to flight ops in March, automatic sync re-enabled in June to remove manual entry, reposition and time-based sync fixes in September.
  • Recreated the Flight Inquiry and Operational Analysis reports from platform data so accounting could self-serve; added weekly flight-existence parity checks on both flight-ops paths.
  • Scoped the passenger and cargo weight sync to NavBlue flight planning: standard versus non-standard trips, total payload calculation, and re-send triggers.
  • After a visit to the merger partner's headquarters, led the relationship, requirements fit, vendor coordination, and internal alignment that secured their agreement to beta the platform for charter operations.

Outcome

  • 100% of charter operations on the new platform; delivered under budget.
  • 80 users trained; CBTs in place for ongoing onboarding.
  • Duplicate-segment defect solved at the match-key level, not patched downstream; manual flight entry removed once automatic sync was restored.
  • First cross-carrier adoption of the platform: a merger partner committed to a charter-operations beta, making this the combined carrier's charter platform ahead of integration.
Open as a standalone case study

Flagship

2025 – 2026·Product owner: requirements, UI/UX loop with the schedule planner, vendor delivery specs, QA coordination

Replaced a single-purpose upload tool with an in-house application that validates every IATA SSIM schedule file before it reaches two downstream vendor systems, and converts local-time schedules to UTC on the way.

  • IATA SSIM
  • CAE AMDM
  • Merlot
  • AWS Lambda / S3
  • Pulumi
  • Python
  • MuleSoft

Challenge

Schedule files flowed to the maintenance-planning system (CAE AMDM) and the crew system (Merlot) with no validation gate. Bad airport codes, unknown aircraft types, duplicate flights, and local-versus-UTC mistakes surfaced downstream, in vendor systems, after the fact. The pipeline also had to keep flowing through the flight-ops platform migration with strict IATA SSIM conformance.

Approach

  • Compared an AWS Lambda proof of concept against a MuleSoft proof of concept and chose the architecture; ran UI mockups through a feedback loop with the schedule planner who uses it daily.
  • Specified the validation rules: airport and aircraft-type cross-checks against the vendor master lists, duplicate-flight prevention per flight number and UTC day, effectivity-date validation, and UTC date-cutoff trimming with a review-and-approval step.
  • Added local-time auto-detection with UTC conversion for AMDM delivery, plus a CSV export carrying local date, time, and service type.
  • Opened a second delivery path: parsed CSV to the crew system with REMOVED-flag handling, and an AMDM parity check that compares delivered legs to processing results and emails on mismatch.
  • Moved the infrastructure from SST to Pulumi; added QA automation for the validation UI; drafted the stateful rework that diffs new uploads against the delivered schedule and sends updates instead of full reloads.
  • Applied working knowledge of IATA SSIM Chapter 7 (fixed-width 200-character records, Record Type 3 period semantics, weekday encoding, UTC offsets) and built Python tooling for generation, validation, and analysis.

Outcome

  • Every schedule file is validated before it reaches either vendor system; delivery is auditable end to end.
  • Documented a structural constraint (period-based records cannot express a time-of-day cutover) that directly shaped the migration cutover-window plan.
  • Unblocked larger schedule files early with an upload-limit release in April 2025 while the full product was built.
Open as a standalone case study

Flagship

Merger period · ongoing·Program manager for both EFB programs and the converged target state

Running two separate FAA-compliant Electronic Flight Bag programs in parallel through an airline merger, while designing the converged target state.

  • EFB platforms
  • AeroData
  • FAA authorizations

Challenge

Post-merger, the two carriers must operate under separate FAA EFB authorizations until a Single Operating Certificate is granted, roughly a 14-month window. Compliance continuity had to hold for both programs simultaneously, with no gap in either authorization.

Approach

  • Owned compliance continuity for both EFB programs in parallel, plus the target-state convergence design for the combined operation.
  • Managed hardware logistics at scale: device asset tracking across 11 stations, assignment auditing, and gap remediation.

Outcome

  • Both programs maintained FAA compliance through the dual-certificate window.
  • Converged target-state EFB program designed ahead of the Single Operating Certificate.
Open as a standalone case study

Flagship

2026 · live Sep 21, 2026·Program lead: stood the program up from zero

Led an airline's readiness for a new FAA data-sharing and flight-management program with a fixed regulatory go-live, delivered on the date while carrying the platform migration.

  • FAA SMART/FMDS
  • NavBlue NFP
  • ACARS / CPDLC

Challenge

A new FAA program arrived with a fixed regulatory deadline and no existing program structure inside the airline: no documentation, no tracking, no scoped workstreams.

Approach

  • Built the foundational program documentation and tracking structure from scratch.
  • Scoped the workstreams: FAA portal account provisioning, flight-plan filing integration with the flight planning system (NavBlue NFP), and a fleet-wide CPDLC/ACARS datalink equipage inventory.
  • Coordinated delivery across SRE/infrastructure, datalink engineering, and vendor contacts.

Outcome

  • Live on the regulatory date, September 21, 2026.
  • Program stood up from zero with clear workstreams and owners.
Open as a standalone case study

Additional programs

Apr 2025 – Dec 2025·Product owner

Replaced a paid third-party flight-times API with an in-house Kronos feed for estimated and actual times when ACARS is unavailable; delivered under budget and ahead of schedule.

  • Kronos / UKG
  • CAE Movement Manager
  • ACARS
  • MuleSoft

Challenge

Estimated and actual flight times fell back to a third-party API whenever ACARS was unavailable, at a recurring annual cost. The replacement had to match the data quality and then carry forward into the new flight-ops platform.

Approach

  • Shipped the FlightView decommission and Kronos implementation in April 2025.
  • Carried the feed into the CAE Movement Manager program: flight-message integration with five-minute ETA collection, a five-minute delta threshold, and immediate OFF/ON events; QA'd and demoed in December 2025.
  • Produced the system diagrams for the CAE, charter platform, and Kronos data flows; later added logic to preserve ACARS times when Kronos or FAA data arrives.

Outcome

  • Recurring third-party API cost removed; delivered under budget and ahead of schedule.
  • Feed re-targeted to the new system of record without a gap.
Open as a standalone case study

Mar – May 2025 · maintained through 2026·Product owner

Gave the operations control center a flight-schedule feed into the SlickOR slot optimizer, used to reduce passenger delay minutes during ATC programs.

  • SlickOR
  • MuleSoft
  • AWS S3
  • CAE Movement Manager

Challenge

The OCC wanted to run an ATC slot optimizer, but it needed a reliable, correctly mapped schedule feed from the flight-ops system, and the flight-ops system was about to change.

Approach

  • Defined the file schema and data queries (required versus optional fields), built the CSV, and delivered it as a MuleSoft scheduler dropping to S3; cleared the AWS role blocker with infrastructure for production.
  • Mapped ETA/ETD and scheduled times, taxi times, and passenger counts; later switched the data source from the legacy system to CAE Movement Manager and prepared the passenger-count source for Navitaire.

Outcome

  • Feed live May 28, 2025 and carried across the platform migration without interruption.
Open as a standalone case study

Dec 2024 – 2026·Product owner for the legacy flight-ops and maintenance applications

Assessed 20+ legacy maintenance and operations modules for retirement, kept the legacy flight movement system stable through its last two years, and shipped the reference-data changes nobody else owned.

  • Legacy AIS suite
  • Legacy FMM
  • Navitaire
  • Trax
  • PHP / Composer

Challenge

The team charter was to retire a legacy application suite module by module to cut maintenance cost, while the same legacy flight movement system had to stay reliable until the new platform went live.

Approach

  • Ran use-case and impacted-business-unit analysis across 20+ maintenance and operations modules (aircraft records, work orders, reliability, audits, vendor lists, and more) and identified low-usage applications and unused charter components for decommissioning.
  • Stabilized FMM: fixes for comment rendering, flight-loading errors, status reverting on tail removal, blank-screen and OOOI-edit defects; airport-code priority (IATA, then FAA, then ICAO) to stop missing records in maintenance actuals; a 31-day query limit after broad queries crashed the system; a hotfix that ended recurring crashes from the anomaly finder.
  • Decoupled legacy reports and the vouchers app from the flight-leg dependency, positioning Navitaire as the system of record; carried a nine-month PHP/Composer platform upgrade through SRE and DevOps to closure.
  • Owned the stations and airports reference apps: audit fields, vendor and de-ice decoupling, removal of the airports dependency as a CAE prerequisite, and an airport-code transition cut over in August 2026 with database inserts, service restarts, crew-system entries, and vendor static-data coordination.

Outcome

  • 20+ modules assessed with retirement paths and business owners identified.
  • FMM crashes and repeated alerts stopped; the legacy system carried stable to the migration.
  • Airport-code transition completed across the ecosystem in one coordinated cutover.
Open as a standalone case study

2025 – 2026·Product owner for the integration platform backlog

Moved the integration estate to MuleSoft CloudHub 2.0, added disaster-recovery configurations and secrets hardening, and built the QA automation that now guards every CAE sync.

  • MuleSoft / CloudHub 2.0
  • JBoss / Spring Boot
  • OpenShift (OKD)
  • Kafka
  • NavBlue NFP
  • Trax
  • Dynatrace

Challenge

A dozen MuleSoft apps, JBoss and Spring Boot services, and vendor syncs had accumulated platform debt: an old runtime, no DR configuration, credentials in request headers, and manual regression testing.

Approach

  • Migrated five integration apps to CloudHub 2.0 in July 2025, coordinated across every air-operations team; upgraded the Mule runtime to 4.9 and cleared tech debt (parent POM, trust store, email apparatus, async-scope timeouts).
  • Moved JBoss and Spring Boot builds from OKD v3 to v4; supported Kafka dead-letter topics in production.
  • Added disaster-recovery configuration for the NavBlue and Trax integrations (endpoints, CLI script, documentation) and a Trax 2.0 replica environment; hardened the Trax-to-NavBlue sync with a three-minute timer, an operating-count fix, duplicate-message handling, and post-production monitoring.
  • Converted API request headers to managed secrets; set up environment configuration and a feature flag for the CAE authentication token.
  • Built MUnit coverage for the charter sync and QA automation suites for Navitaire passenger sync, weight sync, CAE sync, SSIM validation UI, insert-on-not-found, and closed-on-OOOI; managed the release-testing transition and QA lead backfill; piloted an AI coding agent for Mule integration work.

Outcome

  • Integration estate on a current, supported platform with DR paths documented.
  • Regression for every CAE-facing sync automated ahead of cutover.
Open as a standalone case study

02 · Timeline

Milestones

Newest first. Click a milestone for the detail and the program it belongs to.

    • Go-live release scheduled after the parallel-run groundwork, comment-template backfill, and the new platform tile in the internal ops portal.
    • Every tracked dependency closed; risk register empty for the four sprints before cutover.
    Program: Flight Operations Platform Migration
    • Program stood up from zero: documentation, tracking, scoped workstreams, named owners.
    • Same month: reposition and time-based passenger sync fixes, header-secrets conversion, and flight status closed on OOOI receipt shipped for the charter platform.
    Program: FAA SMART/FMDS Compliance
    • Tested end to end the sprint before; cut over August 18 with no downstream fallout.
    • Local-time button restored on the legacy schedule and mileage views the month before.
    Program: Legacy Suite Retirement and FMM Stabilization
    • Stations Contact decoupled from the legacy airports app, a prerequisite for CAE.
    • Automatic flight-ops sync to the charter platform re-enabled; manual entry removed.
    • Nine-month PHP/Composer platform dependency carried through SRE and DevOps to closure.
    Program: Flight Operations Platform Migration
    • Booked counts at T-24h and T-3h, actual counts on departure; TCP patch the following month.
    • Legacy anomaly-finder hotfix in April ended recurring FMM crashes and repeated alerts.
    Program: Charter Operations Platform
    • Flight creation, OOOI times, and flight updates synced from the legacy flight movement system.
    • Full MUnit coverage on the sync app before the first production traffic.
    Program: Charter Operations Platform
    • ACARS refactored from RabbitMQ to the new broker as primary; raw ACARS forwarding to CAE via MuleSoft.
    • SSIM validation app backend and UI deployed and connected; Kronos flight messages to CAE QA'd and demoed.
    Program: Flight Operations Platform Migration
    • Lower environments fed with the live ACARS stream ahead of UAT after a DevOps escalation.
    • Vendor escalation resolved: critical messages not triggering the NavBlue flight sync.
    Program: Flight Operations Platform Migration
    • Vendor's unannounced platform upgrade dropped all inbound traffic in August; escalated for an ETA and a stable fix.
    • Aircraft equipment types standardized to IATA across every integration beforehand.
    Program: Flight Operations Platform Migration
    • Outbound CloudHub IP whitelisted for NavBlue disaster recovery; DR configuration followed in September.
    • OCC managers able to modify OOOI times; FMM airport-code priority fixed missing maintenance actuals.
    Program: Integration Platform, Resilience, and Quality
    • Field mappings for ETA, ETD, scheduled times, and taxi times defined with the OCC.
    Program: ATC Slot Optimizer Schedule Feed (SlickOR)
    • SSIM upload size limit raised the same month, unblocking larger schedule files.
    • CAE Crew Manager technical workshop opened the vendor relationship for the migration.
    Program: Kronos Flight-Times Feed (FlightView API Decommission)
    • Duplicate-message handling refactored and post-production monitoring set up for both integrations.
    Program: Integration Platform, Resilience, and Quality
    • Retirement discovery began across 20+ maintenance and operations modules.
    Program: Legacy Suite Retirement and FMM Stabilization

03 · Systems

The integration architecture I work in

Legacy sources feeding an API-led middleware layer, a flight-ops system of record at the center, and the downstream consumers that keep the airline moving.

Legacy & sources

Integration layer

System of record

Downstream consumers

Hover or tap a system to see what connects to it.

04 · How I work

Spec first, release discipline, risk instincts

Spec-first delivery

Every integration change ships with a complete, developer-ready ticket: business value, scope and out-of-scope, Gherkin acceptance criteria, artifact and config changes, and a rollback plan.

Release discipline

Standardized pre-release checklists (DB changes? scripts? config? firewall? vendor test dependencies?), per-environment deployment tracking, and semi-dark releases before anything goes big-bang.

Risk instincts

  • Vendor provisioning is always the critical path. Flag it first, document the timeline.
  • Date and timezone boundaries are a systemic integration risk, not an edge case.
  • Fix the match key, not the duplicate. A root cause at the data model beats a downstream patch.
  • Release semi-dark first. A secondary path with real traffic beats a big-bang cutover.
  • Run parity checks on both paths, weekly, before anyone asks for them.
  • Undefined status triggers (what actually sets a flight to closed?) are documented gaps waiting to become defects.

05 · Skills

Stack and systems expertise

Click a skill to highlight the programs where I used it.

Airline platforms

Integration & infrastructure

Data & standards

Product & delivery

06 · Credentials

Certifications

In progress

Certifications will be listed here as they are earned.

Contact

Working on airline operations technology?

A platform migration, a vendor program that needs an owner from contract to release, or an integration backlog that needs a technical product lead. Reach out.

claudio.mirabal19@gmail.comgithub.com/claudiooo-codes