Replacing your FIDS: a checklist for regional airports

A vendor-neutral list of what to gather, what to ask and how to switch systems without losing a screen.

1. Why airports replace

Most regional airports replace a flight display system for one of a few reasons. Write down which ones apply to you; they become the goals you measure every proposal against.

  • The vendor is discontinuing the product or no longer supports your version.
  • Servers or display players have reached end of life, and replacement parts are hard to find.
  • The contract is expiring, and renewal is a good time to compare options.
  • Staff can't make routine changes themselves and have to wait on the vendor for simple fixes.

2. Before you write the RFP

Gather the facts about what you have today. Vendors can only price and plan accurately from a clear inventory.

  • Every screen: its location, size, orientation, what it shows and the player or computer behind it.
  • Who changes flight information today, how they do it and how long a change takes to reach the screens.
  • Who troubleshoots a blank or frozen screen, and who they call.
  • Whether the airport website shows flight information, and where that feed comes from.
  • Growth plans such as added gates, a new baggage claim or terminal work, so the new system is sized for them.

3. Questions to ask every vendor

Ask each vendor the same questions in writing so the answers can be compared side by side.

  • Where is the system hosted, and who maintains and updates the servers?
  • What has to be installed at the airport, and who looks after it?
  • Can our existing screens and players be reused?
  • How does staff correct a time, gate or baggage claim, and how quickly do the screens update?
  • How do we add a charter or unscheduled flight?
  • What do passengers see if the internet connection or the flight data drops?
  • How are screens monitored, and who notices when one goes offline?
  • What are the support hours and response objectives, and what happens after hours?
  • Can we put an emergency message on every screen at once, and who is allowed to do it?
  • Can the same flight information feed the airport website or be reached through an API?
  • How does the system address accessibility, such as contrast, text size and readable layouts?
  • Will you complete our security review, and who owns the flight and configuration data if we leave?
  • How is pricing structured, what is included, and is the price protected for the full term?

4. Planning the cutover

A replacement goes smoothly when passengers never notice the switch.

  • Keep the old system running until the new one is verified on every screen.
  • Test every screen in place, including delays, cancellations and gate changes.
  • Train each role on the tasks it owns, from flight corrections at the operations desk to screen checks by IT.
  • Plan a go-live watch: someone walks the terminal during the first busy periods with a direct line to the vendor.
  • Agree in advance what would make you switch back, and how you would do it.

Want to see how one system answers these questions? Schedule a demo.