Migration Paths: Coexisting with Legacy Inventory

1. Executive Summary & Plain Definitions

Airlines want modern Offer & Order retailing (dynamic availability, continuous pricing, attribute bundles) but still rely on a legacy Passenger Service System (PSS) / host for core inventory decrements, schedule integrity, ticketing, interline settlement, and dozens of embedded processes. A “big bang” replacement is rarely feasible. Coexistence—running new and old side-by-side with controlled domain carve‑outs—is the pragmatic path.

Plain Definitions (No Jargon)

• Legacy Inventory / Host: The existing core system that tracks seats, booking classes (RBDs), and tickets.
• Modern Inventory Facade: A new API layer giving a cleaner interface while internally calling legacy functions.
• Offer Engine: Service that builds priced product proposals (seat + features + price) before purchase.
• Order: The future consolidated record replacing separate PNR + e-ticket + EMD structures.
• Coexistence Pattern: A deliberate method describing which system reads, writes, or mirrors a domain object during migration.

Key Idea: Shrink the legacy system’s surface area to the few things it does best (authoritative seat decrement, regulatory clearing, deep interline), while surrounding it with modern services and gradually internalizing those remaining responsibilities.

2. Problem Framing & Constraints

Goal: Introduce modern retail capabilities without losing reliability, auditability, or partner interoperability.

Constraints: High change cadence risks outages; certification with partners; regulatory retention of ticket artifacts; complex refund/exchange logic coded in legacy.

3. Migration Drivers vs Stall Forces

4. Scope of Truth Matrix

Define, for each domain artifact, who is authoritative (Write), who is a subscriber (Read), and transitional notes.

5. Coexistence Patterns (Catalog)

1. Strangler Facade: New API sits in front; routes some calls to modern services, others to host. Gradually rewires underlying endpoints.
2. Shadow Mode: Modern service processes requests in parallel (read-only) to measure divergence before switching writes.
3. Dual Write with Reconciliation: Both host and new system receive writes; periodic diff & repair ensures drift detection.
4. Event Sourcing Wrapper: Capture host transactions as events, rebuilding state externally to validate completeness.
5. Carve-Out by Product: Move ancillaries, seat selection, bundles first (lower coupling) while core seat inventory stays legacy.
6. Channel Segmentation: Direct + mobile use new Offer path; GDS/EDIFACT remain legacy until interline maturity.
7. Temporal Cut (Forward Only): All new departures after date X use new pricing path; older inventory remains host-driven.
8. Market / O&D Slice: Pilot on a subset of markets (e.g. domestic short-haul) to minimize risk radius.

6. Pattern Selection Decision Tree

7. Domain Boundary Redraw (Target)

Split monolith responsibilities into bounded contexts:

• Inventory Core: Capacity pools & decrement transactions (idempotent).
• Offer Composition: Price + product assembly (stateless aside from caching).
• Order Management: State machine of customer entitlements & servicing actions.
• Settlement & Accounting: Ledger, revenue recognition, external clearing adapters.
• Ancillary Services: Seat map, baggage, bundles (feature availability service).
• Context & Eligibility: Loyalty tier, corporate contract, regulatory constraints.

8. Conceptual Diagrams

9. Phase Roadmap (0–36 Months)

1. 0–3 Months Discovery: Inventory dependencies, classify APIs by change risk, instrument baseline divergence metrics.
2. 4–6 Facade & Events: Deploy API gateway; implement publish of host booking/modify/cancel events with schema & sequence numbers.
3. 7–12 Shadow & Carve-Out: Shadow availability & pricing; move ancillaries + rich content to new services; start dual IDs (orderId + PNR).
4. 13–18 Dual Write Core Orders: Orders persisted natively + mirrored to host PNR; reconciliation jobs; limited dynamic pricing live on direct.
5. 19–24 Attribute Capacity Pilot: Parallel tracking of attribute pools; offer engine consumes them for selected markets.
6. 25–30 RBD Suppression (Direct): Direct channel commits via order only; host receives derived booking for compliance. Begin ticket minimization (virtual coupons).
7. 31–36 Interline & Settlement Evolution: Introduce order-based clearing adapter; expand attribute capacity to majority of network; methodically reduce RBD reliance to exception cases.

10. Operating the Hybrid World

• Dual Provenance: Every response includes legacyVersion & modernVersion to audit decision path.
• Channel Flags: Response metadata states pricingMode=LEGACY|HYBRID|MODERN.
• Fallback Policy: If modern service latency > threshold (e.g. 500 ms) route to legacy and log fallback reason.
• Data Freshness Budget: Decide acceptable delay (e.g. 60s) between host capacity change and modern projection update.

11. Availability & Control Bridging

Key challenge: preventing divergence between host seat counts and modern attribute-based offers.

• Event Stream: Host emits seat decrement events with sequence & idempotent key.
• Projection Service: Consumes events, updates attribute pools (e.g. Flex, Light, BusinessPlus).
• Gap Detection: Sequence skip triggers snapshot pull & re-sync.
• Version Fencing: Offer commit must cite inventoryVersion; mismatch forces revalidation.

12. Order / Ticket Duality & Transition

Phase A: Create order + PNR + ticket; both reference each other. Phase B: Order primary; PNR minimal skeleton; ticket virtualized. Phase C: Order only; produce bridging artifacts for external clearing.

• Virtual Coupon Model: OrderItem lines produce pseudo coupon IDs for accounting; include decomposition (base, taxes, ancillaries).
• Servicing: Exchanges apply deltas to Order ledger; host receives simplified notification.

13. RBD → Attribute Capacity Migration

1. Define attribute taxonomy (flexibility, change penalty, baggage, seat pitch, lounge, priority).
2. Map existing RBD -> attribute set (v1 mapping table with versionId).
3. Track attribute-level capacity shadowing RBD bookings.
4. Introduce attribute-based availability endpoint (internal) with RBD “shim” translator.
5. Switch direct channel to attribute endpoint; maintain partner RBD translation.
6. Optimize RM to produce protection levels by attribute cluster, not just RBD nesting.

14. Data, Events & Reconciliation

Event Schema (Illustrative)

SeatDecrementEvent {
  eventId, sequence, flightLegKey, rbd, seats: -1,
  cause: BOOK|CXL|INV_ADJ,
  hostTimestamp, producer="host"
}

OrderCreated {
  orderId, channel, items[], total, currency, pricingVersion,
  inventoryVersion, refPnrId?, createdAt
}

Reconciliation Types:

• Inventory Drift: Compare host seat counts vs projected attribute pool hourly.
• Order Linking: Missing PNR reference vs orderId after X minutes triggers repair job.
• Tax Consistency: Recompute tax on stored order components to detect rule updates.

Data Lineage: Each order stores a provenance object referencing pricing model, mapping version, tax table version, guardrail set.

15. Risk Register & Mitigations

16. KPIs & Observability

• Inventory Divergence Rate (# mismatches / 1000 availability responses).
• Fallback Rate (% requests routed back to legacy path).
• Order ↔ PNR Link Lag (p95 seconds until dual reference resolves).
• Attribute Coverage (% of direct offers using attribute capacity).
• Operational MTTR (median minutes to resolve coexistence incidents).
• Reconciliation Drift Time (average minutes a drift persists before repair).
• Change Failure Rate (deploys causing rollback / total deploys).

17. Ops Runbook & Incident Handling

1. Detection: Alert triggers on divergenceRate > threshold or commit failure spike.
2. Scope: Identify flight/date, channel, pricingMode, versions.
3. Compare State: Pull host snapshot vs projection hash.
4. Classify Root Cause: Gap, latency backlog, mapping version mismatch, dual write failure.
5. Mitigation: Force snapshot sync; temporarily route affected O&D to legacy path.
6. Audit Log: Append incident record with cause, duration, lost revenue estimate.
7. Preventive Action: Add or tune alert, backlog ticket for structural fix.

18. Security, Trust & Integrity

• Signed Tokens: Offer / availability tokens include HMAC over inventoryVersion + expiry.
• Replay Protection: Nonce or short TTL on commit tokens to prevent stale re-use.
• Least Privilege: Modern services use scoped credentials; facade enforces domain ACLs.
• Data Integrity Checks: Hash chain of event sequences; gap triggers tamper alert if unexpected.

19. Interline & Alliance Transitional Strategy

• Partner Transparency: Share migration schedule & fallback semantics with partners early.
• Continuous-to-Discrete Mapping: Provide anchor fare & adjustment fields; limit variance to negotiated corridor.
• Token Handling: If partner cannot consume offer token, include canonical fallback record.
• Proration Adapter: Splits dynamic total across sectors by weighted mileage or demand-based weighting, logged for audit.
• Monitoring: Track proration variance delta vs internal expected allocation.

20. Revenue Accounting & Settlement Adaptation

Interim: Orders + tickets coexist; accounting uses ticket coupons as primary but logs order decomposition for audit. Later: Order line ledger drives revenue recognition; produce “clearing view” transforms for BSP/ARC until industry order clearing matures.

• Decomposition Ledger: baseFare, adjustments, ancillaries, taxes, fees each with version/tax rule reference.
• Rebuild Function: Reconstruct filed baseline vs sold to validate compliance.
• Exchange Handling: Delta ledger entries rather than re-issuing full value recalculations where possible.

21. Governance & Change Management

• Operating Model: Cross-functional migration council (Architecture, RM, Distribution, Accounting, Ops) with RACI matrix.
• Decision Log: Document pattern adoption decisions & retirement criteria for legacy endpoints.
• Phase Exit Gates: Must meet KPI targets (e.g., divergenceRate < 0.2%) before next phase.
• Communication Cadence: Weekly readiness review; monthly exec checkpoint on value metrics.

22. Implementation Checklist

• Map domain artifacts and assign authoritative system owner.
• Deploy facade gateway with routing & version headers.
• Stand up event bus: seat, order, price provenance events.
• Implement sequence + gap detection & snapshot reload.
• Shadow availability & pricing: collect divergence metrics.
• Carve-out ancillaries & rich content to new services.
• Dual write orders (order + PNR) with reconciliation job.
• Introduce attribute capacity shadow tracking.
• Add Offer tokens (inventoryVersion, pricingMode, expiry).
• Dashboard KPIs: divergence, fallback, link lag, coverage.
• Risk register updated monthly; mitigation owner named.
• Order-to-ticket virtual coupon mapping for accounting.
• Interline fallback anchor / adjustment handshake defined.
• Security: token signing, replay protection, audit log immutability.

23. Plain-Language Glossary

• Facade: New interface masking old system complexity.
• Shadow Mode: Running new logic silently in parallel to compare results.
• Dual Write: Writing the same change to both old and new stores.
• Divergence: Difference between states in legacy vs modern view beyond tolerance.
• Attribute Capacity: Availability expressed via product features instead of booking code letters.
• Virtual Coupon: Transitional accounting record linked to an order item.
• Strangler Pattern: Gradually replace old system by wrapping and redirecting pieces.
• Fallback: Automatic revert to legacy path when new path unstable.

24. References & Disclaimer

• Public industry materials on Offer & Order concepts (IATA publications).
• Conference presentations (AGIFORS, T2RL, PODS) on migration & inventory modernization.
• General software architecture patterns (strangler, event sourcing, dual write) publicly documented.
• Public vendor whitepapers describing modern retailing approaches (verify specifics directly).

Trademarks and product names belong to their respective owners. No endorsement implied.

Back to all blogs