Complex Aviation Data Migration
Airline revenue accounting, passenger and cargo, holds every ticket and air waybill from sale to settlement. Replacing the system means moving the open book, tickets with unflown coupons, uplifts without a sale, waybills not yet billed, into a system that models the lifecycle differently, and proving to the ledger, to the cent, that nothing was gained or lost.
Why Revenue Accounting Migrations Are Difficult
We have migrated passenger and cargo revenue accounting. The systems around them raise the same questions with their own documents. Each one is a business question before it is a technical one.
A ticket is a lifecycle, not a record
Sale, coupons, exchanges, refunds, uplift, matching, revenue recognition. Every open document is somewhere in the middle of that life, and the target holds the stages differently: an exchange chain may become a single sale, a flown coupon an "unknown usage". The migration has to re-create the state of each document in the new model without moving revenue that was already recognised.
Only open items move; history stays
Fully used sales do not migrate. What moves is the open book: journeys with at least one unflown coupon, uplifts with no matching sale, documents with a remaining balance. Defining "open", and listing what stays behind (settled interline, refund requests, card data, invoices), is the scope of the migration and has to be agreed before anything else.
Unearned revenue must agree to the cent
The value of the migrated open coupons is the unearned revenue in the general ledger, by sales month and currency. Counts and values are compared per file at every stage: extracted, loaded to the staging tables, loaded to production, posted. The migration is accepted when the figures match, not when the load finishes.
Proration is decided once
Gross, net, and net-net coupon values, reported and calculated taxes, standard and supplementary commission were prorated in the legacy system and already posted. Migrating those values rather than re-prorating in the target keeps the books consistent; which values exist on each side, and in which currency, is a mapping question on every coupon.
Sales from everywhere, in every currency
BSP and ARC reports, direct and online sales, interline, general sales agents, each with its own periods, agent structures, and currencies, converted to the revenue accounting currency. The source identifies a sale by one set of keys and the target by another; the mapping has to hold for every sales source.
Interline and settlement in flight
Billing between carriers, incoming and outgoing invoices, items under dispute. Positions that cannot be reconciled in the legacy system are not migrated: they are finished there, or captured anew in the target after cutover. The decision for each class of item is taken with the accounting team and the auditors in view.
Cutover follows the accounting calendar
The legacy system closes its last period, error queues are emptied, open items are migrated and proven against the ledger, then the sales and lift data that arrived in the meantime are caught up before normal operation starts. There is no parallel run; the switch has to be transparent to management and auditors.
Master data is rebuilt, not moved
Fare and proration tables, tax tables, agents, flight structures, and ticket number ranges are set up fresh in the target. Every migrated open item has to point at the new master data, so master-data readiness is a prerequisite of the migration, not of the go-live only.
Cargo: the same shape, its own documents
Air waybills instead of tickets; prepaid and charges-collect, other charges, corrections; agents settled through CASS, carriers through interline; stock of waybill numbers to be carried over at go-live; open waybills flown but not billed, billed but not settled. The questions are the same as for passenger: what is open, what does it owe, and who proves it.
Cutover Between Two Accounting Periods
The legacy system completes billing and posting for its last period and empties its error queues. The open items are extracted, migrated, and proven against the general ledger. Sales and uplift data that arrived during the migration are then caught up in the new system, which takes over from the first day of the next period. The old system remains as a read-only reference for everything that did not move.
- Close period
- Open items
- Prove to GL
- Catch-up
- Go-live
Because the switch happens on a period boundary, the proof is a reconciliation finance already understands: the unearned revenue the ledger carried out of the old period is the unearned revenue the new system opens with.
Validate & Prove in the lifecycleWhat This Means for the Project
Scope is a financial statement
The list of open documents and their values is agreed with revenue accounting and finance and reconciled to the ledger before the migration is built. What is excluded is written down with where it will live and who can still see it.
Full simulations before the real run
The migration is rehearsed at least twice on complete extracts, with the statistics compared at every stage and the differences explained. The cutover window and the catch-up are part of the rehearsal, not an afterthought.
The legacy stays available for audit
Non-migrated history remains accessible, read-only, in the old system or a viewer, for as long as the auditors and the interline partners may ask. The migration plans that access rather than assuming it.
Passenger Revenue Accounting Migration
Replacement of an airline’s passenger revenue accounting system: open-item migration, reconciliation to the ledger, and cutover on a period boundary.
Read the case studyPlanning an Aviation Data Migration?
Let's examine the source environment, target objectives, and migration challenge.