A 30-year refund mainframe, retired with zero downtime

The passenger refund system was the system of record for every refund the airline processed — fare reversals, taxes, baggage charges, partial-use coupons, weather cancellations, involuntary cancellations during irregular operations. It ran on an IBM mainframe that had been in production for three decades. Refunds are a regulated financial workflow: access controls, document retention, and reconciliation are all audit-scoped.

The deadline was non-negotiable on two axes. A federal regulatory mandate required automated passenger refunds by October 2025. At the same time, IBM was exiting its cloud business and retiring the platform underneath the existing system. The migration window could not include a single minute of downtime — the mainframe was processing live customer refunds throughout, and any visible drop in availability would have been a regulator finding.

The rebuild is a twenty-service event-driven platform on Azure with a business-team-maintainable rules engine, document-store persistence with full event history, end-to-end observability, and a parallel-run cutover that reconciled outputs against the mainframe in real time before takeover. The review console in the demo above is one piece of the surface: it's where reviewers land for the requests the rule engine deliberately stops on.

Migrating off a 30-year mainframe under a federal deadline with zero allowed downtime gives every architectural decision the same test: does this hold up while the old system is still running, and can the business team keep it running after we ship?

I own the rule engine end to end. The validation service that checks request shape and integrity. The eligibility orchestrator that gathers enrichment — fare rules, endorsement restrictions, agency codes — before forwarding to the determiner. The determiner itself with channel-specific rule packages for web, mobile and agency flows, defined as decision tables the business team maintains. And the eleven-rule quality controller — checks like whether the refund amount exceeds the original sale, whether it's being issued via paper check, whether it crosses thresholds requiring secondary review — that gates auto-clear versus the manual review queue.

On the front end I built and currently maintain the React review console for the requests automation deliberately stops on. Redux Toolkit owns client-side audit state, TanStack Query owns server state, TanStack Router gives each view a typed route, React Hook Form owns the multi-field correction forms. Real-time updates stream over the message bus so the reviewer's view stays current as requests move through release and downstream post-processing without a refresh. The customer-facing Angular refund workflow UI ships alongside (standalone components, RxJS, OnPush change detection).

Tests were BDD-first with Cucumber on the rule engine — the business team co-authored scenarios before any rule shipped, so every rule change is regression-tested against business intent. The observability stack the team still relies on for on-call covers throughput and percentile-latency dashboards, distributed tracing across services, and log aggregation. The cutover ran parallel with a reconciliation layer comparing outputs in real time; we didn't switch over until divergence held at zero on production traffic. Zero downtime, zero refund discrepancies through the migration window.