Passenger Revenue Accounting System Migration

The Challenge

Airline revenue-accounting data has a lifecycle. A ticket is not a row in a database.

The migration had to decide the treatment of every population and transaction state, including:

• passenger tickets and coupons
• open ticket balances
• sales and uplift
• taxes, reported and calculated
• interline transactions
• refunds and exchanges
• ACM and ADM memos
• work-in-progress and unmatched transactions
• the accounting switch-over itself
• reference and airline-specific master data

That turns the migration question around. It is no longer "which source field maps to which target field?"

It becomes: "What is the business and accounting state of this document at cutover, and how must that state be represented in the new revenue-accounting system?"

Reconciliation and Proof

A migration is not proven because the data loaded. It is proven when the result reconciles.

Reconciliation was structured across business dimensions rather than as one total. Each migration population was compared between source and target in amounts and in counts, and the differences were presented in views the finance team already used: by ticket status, by accounting period, by agency, and by currency.

Every difference between source and target is a visible, assignable exception with a business meaning, instead of a data problem found later by someone else.

Migration success is not "the program ran successfully." It is "we can account for every difference between source and target."

Beyond the Core Accounting System

A core-system migration does not end at the application boundary.

Revenue-accounting information is consumed well beyond the revenue-accounting application: the general ledger, management reporting, settlement, and the systems that read ticket and coupon data for their own purposes. The migration therefore defined how migrated items would appear to those consumers, which of them should be reported and posted from the new platform and which must not be reported twice, and how reporting continuity would hold across the switch-over.

Replacing a core system is not complete when the new application works. Its data must continue to serve the enterprise around it.

The Outcome

From legacy complexity to a controlled revenue-accounting transition.

The new platform went live on the date set in the initial plan. The migration carried the open passenger revenue accounting population into it with its business state, balances proven to the ledger, exceptions decided and recorded, and reconciliation evidence by population, period, agency, and currency.

Transformation decisions were tied to the financial meaning of the airline’s data rather than treated as a database exercise. The source analysis, the mappings, the decision log, and the reconciliation workbooks remain as the record of why each balance is where it is.

The project demonstrates work at the intersection of complex legacy data, airline-domain semantics, financial controls, and enterprise-system replacement. That is the capability we bring to the next one.