Aircraft Maintenance Software: How to Choose the Right System

The five systems commonly sold as maintenance software

Some platforms span multiple rows. That can reduce handoffs, but “all in one” is not the same as depth in every workflow. Ask vendors to demonstrate the functions you will actually use.

Radar belongs primarily in the aircraft-records layer. It digitizes, connects, searches, and structures maintenance records so a reviewer can move from a fact to its supporting page. It is not a full MRO ERP and does not make maintenance-release or airworthiness decisions.

Start with the operating decision

Write the buying problem as a decision, not a software category:

• “We need to forecast every calendar-, hour-, and cycle-controlled requirement across twelve aircraft.”
• “Technicians need controlled work cards, parts issues, and electronic signoff at three bases.”
• “We need searchable, source-linked records for maintenance review, financing, and sale.”
• “We need one view of deferred work, parts availability, downtime, and cost.”

Then define the unacceptable failure. It may be a missed due item, an unsupported baseline, an unavailable record during an audit, an uncontrolled work-card revision, or inventory allocated to the wrong job. Those failure modes determine the required controls.

Requirements matrix for an operator

Score demonstrations against agreed scenarios. Avoid scoring a capability as “present” merely because a menu label exists.

Maintenance tracking: test the baseline before the forecast

A due list can look precise while resting on a weak baseline. Implementation should reconcile:

• aircraft, engine, APU, propeller, landing-gear, and component identity;
• current hours, cycles, landings, and calendar status;
• maintenance-program revision and task applicability;
• last-complied and next-due values;
• Airworthiness Directive status and method of compliance;
• life-limited-part history and remaining life;
• major repairs, alterations, and associated continued-airworthiness instructions; and
• open discrepancies or controlled deferrals where applicable.

The software should expose assumptions and exceptions. An unsupported value should not silently acquire the appearance of a verified fact because it was loaded into a polished dashboard. See the deeper aircraft maintenance tracking software buyer’s guide for calculation and cutover tests.

Work orders, inventory, and MRO operations

For maintenance providers and larger internal shops, the buying center expands beyond technical records. Evaluate:

• quoting, customer authorization, and scope changes;
• labor planning, skills, shifts, and actual time;
• parts demand, receiving, certification, quarantine, issue, and return;
• tooling, calibration, and controlled consumables;
• task-card revisions, findings, inspections, and approvals;
• outside services, purchasing, invoicing, and warranty;
• mobile or offline execution; and
• customer and regulator package output.

These are operational controls with regulatory consequences, not convenience features. A repair station should map the software to its ratings, manuals, quality system, and applicable rules. Do not assume that a vendor’s generic workflow confers authority or makes a record acceptable.

Records evidence must survive the workflow

14 CFR 43.9 specifies information required for many maintenance entries. 14 CFR 91.417 addresses specified maintenance records, retention, and transfer for owners and operators subject to that section. Other operating rules add requirements.

FAA AC 120-78B provides current guidance for electronic signatures, electronic recordkeeping, and electronic manuals. It is guidance, not a blanket approval for every implementation.

Whatever software creates or stores the record should preserve:

1. the original or authoritative record;
2. aircraft and component identity;
3. the event, work, date, and times;
4. the person and authorization represented by a signature;
5. revisions and corrections;
6. access for the required retention period; and
7. a portable output for audit, transfer, or system exit.

Radar can make existing paper and electronic source material searchable and connect related evidence. A qualified reviewer still decides whether the evidence is complete and supports the conclusion.

Integration without duplicate truth

Integrations often create a second copy of the same status. Define a source-of-truth map before connecting systems:

For every interface, specify frequency, validation, error queues, retry behavior, correction ownership, and audit history. “Real time” is not a control if rejected records disappear unnoticed.

A demonstration that reveals real capability

Give every shortlisted vendor the same representative data and ask it to:

1. load a mixed-quality records package;
2. establish one serialized component’s installation history;
3. configure a recurring hour-and-calendar requirement;
4. enter completed work with its source evidence;
5. update utilization and explain the resulting due date;
6. revise a requirement without losing the prior state;
7. expose a conflict between two source records;
8. restrict a contractor to one aircraft;
9. export the due list, audit history, and original documents; and
10. show recovery from a simulated bad import.

Include technicians, records staff, planners, quality, IT/security, and finance in scoring. The best interface for one team can create hidden work for another.

Implementation plan and measurable acceptance

1. Inventory

List aircraft, systems, spreadsheets, paper archives, interfaces, owners, and known gaps. Back up fragile source records before reorganization.

2. Design

Define field ownership, review roles, naming rules, identity keys, document taxonomy, access, retention, and exception handling.

3. Pilot

Use one representative aircraft, not the cleanest one. Measure import coverage, baseline exceptions, search success, calculation differences, and user time.

4. Reconcile

Resolve material discrepancies against source evidence. Preserve unresolved items in an exception register with consequence, owner, and next action.

5. Cut over

Use a controlled date, approved migration result, rollback plan, and parallel comparison for high-risk outputs.

6. Govern

Monitor late intake, rejected interfaces, overdue exceptions, status changes without evidence, access reviews, recovery tests, and exports.

Useful success measures include time to find supporting evidence, percentage of material statuses with a source link, exception age, intake latency, forecast variance, and time to assemble an audit or sale package.

Questions to ask before signing

• Which product functions are native, acquired, integrated, or partner-delivered?
• Can we export original documents, structured fields, relationships, and audit history?
• How are handwritten records, low-quality scans, and conflicting values handled?
• Who performs migration and who accepts the baseline?
• What calculations have configurable logic, and what changes require vendor support?
• How are program revisions and superseded tasks controlled?
• What does the system do offline or during an outage?
• Which security reports, subprocessors, backup details, and incident commitments are available?
• How does pricing change with tails, users, storage, modules, and implementation work?
• What claims require separate regulatory acceptance or changes to company procedures?

The right aircraft maintenance software is not necessarily the product with the most modules. It is the system, or deliberate system combination, that makes ownership, calculation, execution, and evidence explicit.

Sources and further reading

• FAA AC 120-78B, Electronic Signatures, Electronic Recordkeeping, and Electronic Manuals
• 14 CFR 43.9, Content, form, and disposition of maintenance records
• 14 CFR 91.417, Maintenance records
• Veryon Tracking, current category and workflow overview
• flydocs, digital records management overview