Airport Operational Database Software Problems: The 7 That Cost Airports Real Money
The most expensive failure at an airport is having three sources of flight data and no written rule about which one wins. The airline is authoritative on registration, air traffic control on movement times, the handler on ground events and surveillance on position, and when they disagree the system picks silently or a human patches it. The result is an aeronautical invoice calculated from a maximum take off weight attached to a registration that never flew, disputed weeks later, with nobody in the building able to say which record was correct. Multiply that across a year of movements and the leak is permanent, quiet and larger than any single dispute suggests.
Why does source arbitration always get underscoped?
Projects get written as consolidate flight data into a single record. That sentence hides the entire problem, because consolidation is trivial and arbitration is not. Flight data arrives from the airline schedule, from air traffic control and network feeds, from the ground handler, from surveillance, and from a person on the apron radio. They contradict each other constantly, and the contradictions are not random.
Packaged systems from Amadeus and SITA do carry source priority configuration, and it is genuinely useful. What it expresses is a generic priority ladder. What an airport needs is a rule set that says accept registration from the airline until forty minutes before estimated landing then freeze it, accept actual on block from the handler unless surveillance disagrees by more than three minutes in which case raise an exception rather than pick a winner, and never allow a billing relevant field to change after invoicing without an audit entry.
That is operating policy, not a vendor default, and it changes when your handler mix changes. Nobody costs writing it down, so it gets improvised during build and ends up encoded in whatever the developer inferred from a workshop.
The fix is to treat arbitration as a versioned, testable rule set produced before implementation, with an exception queue a duty officer works. Every field on the flight record carries its source, its timestamp and the rule that let it win. Build the record as an append only event log rather than a mutable row, because that single decision is what makes every later dispute replayable rather than argued from memory.
What goes wrong with stand geometry and legacy flight data?
Two data problems, both underestimated.
The stand rulebook usually does not exist as a document. Adjacency restrictions where a code E aircraft blocks a neighbour, MARS positions that split or combine, wingspan and tail height limits, pushback conflicts on a shared taxilane, jet bridge compatibility by door position, tow rules and who pays, border control routing, night curfew parking and de-icing pad access are all real constraints, and most of them live in the heads of two allocators who have worked there for fifteen years. Extracting them is interview work, and it competes with those allocators' day jobs.
Historical movement data is the second. It exists, but the fields you need for billing evidence are inconsistent: on block and off block times recorded to different conventions, stand assignments overwritten rather than versioned, and aircraft types recorded against registrations that have since been re-registered.
The failure mode is a first allocation run that produces a plan the allocators reject in ten seconds because it puts a widebody on a stand they know it cannot use. After that, the system is a toy.
The fix is a geometry audit as a funded phase: stands, wingspan codes, adjacency pairs, bridge compatibility, tow costs and walking distances loaded as data and validated against last month's actual allocations. If the model cannot reproduce what the allocators did, the model is wrong and you want to know that before go live. For history, migrate what supports billing disputes within your retention window and index the rest rather than trying to normalise everything.
Why do tenant feeds and legacy interfaces break after launch?
Most airports carry a graveyard of scheduled exports, some running from a machine under a desk, each one a silent integration that fails without anyone noticing until a tenant complains. Replacing that with a publish layer fixes the architecture and does not fix the failure mode unless monitoring is designed in.
The interfaces that break hardest are the old ones. A baggage handling system interface and a surveillance feed have different protocols, different failure modes and a decade of local customisation, and the specification sometimes has to be bought back from the original integrator. Teams discover mid project that the document describing the message format does not match what the system actually sends.
The other recurring break is Type B messaging and schedule updates. A message arrives in a variant the parser has not seen, gets rejected, and the flight record quietly holds yesterday's data.
The fixes are unglamorous and they work. Publish once and let tenants subscribe, supporting a small number of shapes including an industry standard exchange format for partners who can consume it and a plain interface plus webhooks for those who cannot. Alert on the feed that did not arrive at all, not only the feed that errored. Hold rejected messages in a queue with the raw payload retained, so a new variant is a ten minute fix rather than lost data. And publish an operational dashboard showing feed health per source, because at an airport the person who notices first should be the duty manager, not the tenant.
What happens when billing evidence and A-CDM milestones are not covered?
Aeronautical billing is only as good as the record beneath it, and the gap is usually evidence rather than calculation. Landing fees by maximum take off weight, parking beyond a free period at rates differing between contact and remote stands, passenger charges split by domestic, international and transfer, noise and emissions surcharges, bridge usage, ground power and de-icing are each formulas over the flight record with airline specific exceptions negotiated into contracts.
When evidence is not designed in, three leaks recur: movements missing from the monthly export, weights taken from a fleet table last updated when the airline flew a different subfleet, and parking durations the airport cannot substantiate when challenged. Every one of those is a dispute you lose by default, because the burden of proof sits with the party issuing the invoice.
Airport Collaborative Decision Making adds a second exposure. Joining a programme means emitting defined milestones with reliable timestamps, and those timestamps are audited by parties outside your control. If your sources currently disagree, the milestones inherit the disagreement, and the programme surfaces it publicly.
The fix is to calculate the charge when the movement closes, from the authoritative record, with tariffs held as versioned data so a mid year change needs no code release, and every invoice line linked to the exact record and rule version that produced it. Then A-CDM stops being a separate project, because reliable milestones fall out of the same arbitration work.
Should you build custom or configure what you already own?
Configure, if you are a single terminal airport under roughly two million passengers with a stable carrier mix. Amadeus Airport Management and SITA Airport Management will give you a configured operational database that does the job, the integration surface is small enough to manage, and money spent on a build is better spent on the apron. We would say that before quoting.
The more common honest answer for mid sized airports is a hybrid. If you already own a vendor system you cannot rip out, keep it as the record for the fields it holds well and build the arbitration, allocation and publish layer around it. That avoids a migration that would consume two years and still gets you the exception handling, audit trail and integrations the configuration model cannot express. Design the boundary carefully so the vendor system is never bypassed silently, which is the failure that makes hybrids worse than either option alone.
Build properly when three things are true together. Your stand and resource rules cannot be expressed in the vendor model and are therefore being applied by humans every day. Aeronautical revenue is large enough that a small billing leak exceeds project cost. And more than about ten tenant systems consume your flight data, which makes the integration layer your largest operational risk.
On the physical layer, keep the specialists. ADB SAFEGATE is strong on docking guidance and gate hardware, and Veovo is genuinely good at passenger flow and queue prediction. Neither is trying to own your stand rulebook, and replacing them is not the project.
How do hidden costs get into the quote?
Legacy interface archaeology is the first. Each old system is its own investigation, and the specification may need recovering from the original integrator at a price. Quotes that price integrations as a count rather than individually are guessing.
Rule discovery is the second and it is the one nobody budgets. Writing down what two long serving allocators know takes their time, in the operation, and no amount of developer effort substitutes for it.
A-CDM is the third. Milestone definitions, message quality and the testing calendar involve parties outside your control, so the schedule is partly theirs.
Multiple terminals with genuinely different operating models is the fourth, because that is not a configuration flag, it is two rule sets and two sets of exceptions.
Parallel running is the fifth. You cannot cut over a flight record on a Tuesday and hope. Running both records side by side for a period, with a daily difference report, is real weeks of operations time and it is what makes the cutover safe.
Ask for those five as named line items with days against them, and ask specifically which of them consume airport staff time rather than developer time, because those are the ones that slip.
What separates a build that works from one that fails here?
The builds that work start with the flight record and nothing else. Scheduled flight, operational movement, the turnaround linking an arrival to a departure, and resource assignments are separate objects, and the arbitration rules sit above them. A team that draws one flights table with an editable status column has built a booking system and will learn aviation on your budget.
They make the record replayable. Append only events with source, timestamp and rule version mean a billing dispute or an incident review is a query rather than a reconstruction, and that property cannot be retrofitted once the schema is load bearing.
They ship the unglamorous publish layer early. Operations teams believe a platform is real when tenants stop calling about missing files, and that usually happens before any optimisation work lands.
They keep the manual override and record the reason. Allocators will always override, and treating those overrides as data rather than as failures is how the rule set gets better each season.
They design for the day everything is wrong. A runway closure, a source feed going silent overnight, a diversion wave. Ask a developer to describe what their system does when a feed stops at three in the morning, because that is a Tuesday at an airport.
And they settle ownership before kickoff: your repository, your cloud accounts, your right to hire another firm. Airports buy systems that live fifteen or twenty years, and a developer holding the repository is selling a dependency you will pay for repeatedly.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey found that tech debt can amount to 20-40% of the value of a company's entire technology estate before depreciation, and CIOs report that 10-20% of the budget for new products is diverted to resolving tech-debt issues. Source: McKinsey & Company (2020) →
- SaaS spend averaged $4,830 per employee (up 21.9% year over year), with large enterprises (10,000+ employees) spending roughly $284M annually and running about 660 apps, while organizations wasted an average of $21M annually on unused licenses. Source: Zylo (2025) →
- Workers can expect 39% of their existing skill sets to be transformed or become outdated over 2025-2030; 77% of employers plan to upskill their workforce, and 63% identify skill gaps as the biggest barrier to business transformation. Source: World Economic Forum (2025) →
- This World Bank report argues that digital technology adoption raises SME competitiveness, productivity and resilience, while documenting that smaller firms consistently lag larger ones in digital adoption - a gap that constrains their growth and market reach. Source: World Bank (2022) →
Liam builds iOS apps at Digital Heroes, from architecture decisions through to App Store submission and the maintenance that follows. He deals with the details buyers rarely ask about: offline handling, background sync, OS upgrades. Read him if you are trying to budget for an app beyond version one.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Our three flight data sources disagree. How do we decide which one wins?
Write the rule per field rather than per source, because authority varies by field and by time. The airline is authoritative on registration until close to landing, air traffic control on actual movement times, the handler on ground events, surveillance on position. Then decide what happens on conflict: some fields take the higher priority source silently, others should raise an exception for a duty officer. Store the source, timestamp and winning rule on every field so the decision is replayable.
Why do allocators override our stand allocation every day?
Because the rules they apply are not in the system. Adjacency restrictions, MARS splitting, wingspan and tail height limits, pushback conflicts on a shared taxilane, tow cost thresholds and border control routing are local to your apron and rarely expressible in a generic allocator. Load that geometry as data, validate the model by replaying last month's actual allocations, and keep the override with a recorded reason so the rule set improves rather than being quietly worked around.
How does bad flight data actually leak aeronautical revenue?
Charges are formulas over the flight record, so every record error becomes a billing error. The recurring three are movements that never reach the finance export, maximum take off weights read from a stale fleet table, and parking durations you cannot evidence when challenged. Calculate at movement close from the authoritative record, hold tariffs as versioned data, and link each invoice line to the record and rule version that produced it. Disputes then take minutes and most stop happening.
Can we keep our existing operational database and build around it?
Yes, and for most mid sized airports that is the sensible answer. Keep the vendor system as the record for the fields it holds well, then build arbitration, stand allocation and the tenant publish layer around it. That avoids a two year migration while giving you the exception handling and audit trail the configuration model cannot express. The design risk is a boundary that lets the vendor system be bypassed silently, so define which system owns which field in writing before any code.
What does A-CDM require from our data before we can join?
Reliable milestones with trustworthy timestamps, which is only possible with one authoritative flight record and settled arbitration between sources. If your sources currently disagree, the milestones inherit that disagreement and the programme surfaces it to partners outside your control. Fixing arbitration is therefore a prerequisite rather than an optional extra, and the milestone work is comparatively small once the record is trustworthy.
How do we stop tenant feeds breaking silently?
Publish once and let tenants subscribe rather than maintaining a scheduled export per tenant, then monitor for the feed that did not arrive at all rather than only for the one that errored. Keep rejected messages with their raw payload so an unseen variant is a short fix rather than lost data, and put feed health on a dashboard the duty manager watches. The goal is that the airport notices before the tenant does, which is rarely true of export based setups.
Which integrations should we budget individually rather than as a group?
Baggage handling, surveillance, Type B messaging, finance and any A-CDM interface. Each has its own protocol, its own failure modes and often a decade of local customisation, and specifications sometimes need recovering from the original integrator. Ask any developer to name the specific systems and message types they have handled rather than claiming integration experience generally, and price each one with its own days.
Is it worth building if we have one terminal and twenty stands?
Usually not. At that scale a properly configured packaged operational database handles the flight record, the allocation problem is small enough for a human with good tooling, and the tenant integration surface is manageable. The case for building starts when allocation rules are being applied manually because the vendor model cannot hold them, when a small aeronautical billing leak would exceed project cost, or when more than ten tenant systems depend on your flight data.
What does it cost to keep custom software running after launch?
Why do companies replace NetSuite with custom software?
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Who owns the source code if an agency builds my ERP?
How long does custom ERP development take?
How long does it take to build a custom web or mobile app from scratch?
Why do agencies charge for a discovery phase instead of quoting for free?
Who can build a custom ERP software system?
Digital Heroes builds custom ERP software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other ERP software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
