Aircraft MRO and Maintenance Engineering Software: Why the Suite You Bought Still Needs a Spreadsheet

Why a maintenance and engineering suite fits almost nobody exactly

It is day four of a C check. The aircraft is on jacks, the check package was released with 412 routine task cards, and the non-routine count is now at 180 and climbing because corrosion turned up in a wing box area that the planner had budgeted eight hours for. The materials team is chasing two AOG parts. The check manager is holding a printed board with coloured magnets on it, because the board is the only place in the building where routines, non-routines, manpower and parts availability appear together. Meanwhile a service bulletin arrived last week superseding an AD terminating action, and an engineer is working out on a spreadsheet whether the mod embodied on tail 704 still satisfies it.

You almost certainly own a real system already. Swiss-AS AMOS, Ramco Aviation Suite, TRAX, Rusada ENVISION, IFS Maintenix and EmpowerMX FleetCycle are serious products with real airline customers. The reason there is still a magnetic board is not vendor incompetence. It is that each suite encodes an assumed shape: a fleet profile, a maintenance program structure, a hangar workflow, a materials model, a way of billing. Your operation is a specific combination of mixed types, inherited paper records, third-party contracts and a maintenance program amended sixty times. The distance between the vendor's assumed shape and yours is filled by people, spreadsheets and printed boards.

The gap has a consistent signature. Technical services rebuild status views by hand every week. Check packages overrun because non-routine growth is discovered on the floor rather than predicted. Third-party invoices go out late and light, because labour and parts were captured on paper and reconciled after the aircraft left. And once in a while, the expensive one: an AD or a life limit tracked somewhere the system cannot see.

Problem 1: AD and service bulletin compliance lives beside the system, not inside it

Every M and E suite has an AD module. Every technical services department also has spreadsheets. The reason is the same everywhere: the AD as issued does not map cleanly onto how the suite wants to hold it. A single AD may carry alternative methods of compliance, an inspection interval plus a terminating action, applicability by serial range and modification status, and a chain of superseding revisions. Encoded as a recurring task with a due date, most of that meaning is lost, so the engineer keeps the real logic in Excel.

This is not entirely fair to blame on a vendor, but it is what happens. The suites model tasks and intervals well and applicability logic less well, because that logic is awkward and differs by regulator, by type certificate holder and by how effectivity records were kept by whoever held the aircraft before you.

What a custom build does: treat applicability as an evaluated rule rather than a static list. Each AD or SB carries conditions over serial number, effectivity, embodied modifications and accumulated cycles or hours, and the system evaluates those conditions against each tail continuously. When you embody a mod, the terminating actions it satisfies flip automatically, and the record of why they flipped is preserved for the auditor. When a revision supersedes, the system shows exactly which tails changed status and which did not. The output your technical services team actually wants is one page per tail that a regulator would accept without a follow-up question, and that page is generated rather than assembled.

Problem 2: the check is planned in a system and executed on paper

Planning happens in the suite. Execution happens on a printed package, a magnetic board and a WhatsApp group. Non-routines are written on cards, photographed, chased by phone and entered later. The consequence is that at any moment during a heavy check, nobody has a live and accurate answer to the only question that matters, which is whether the aircraft will make its scheduled return to service.

EmpowerMX FleetCycle is the strongest incumbent on heavy check execution, and if your problem is purely hangar throughput it deserves a look. The general suites treat execution as status updates against planned tasks, which works when the plan holds and degrades exactly when non-routine growth runs ahead of estimate.

What a custom build does: put the card in the technician's hand on a tablet, capture the non-routine at the point of discovery with photographs and the zone reference, and route it immediately to engineering disposition and materials. The critical path is then computed continuously rather than reviewed at the morning meeting. The check manager sees which non-routines sit on the path to release, which wait on a part with a known ETA, and which need a repair scheme engineering has not started. This is the feature that changes behaviour fastest, because it moves the argument from opinions about the schedule to a shared view of it.

Problem 3: mixed fleets and third-party work break the vendor assumptions

Regional operators rarely have the clean fleet the software imagines. Two or three types, some tails owned and some leased with different return conditions, one subfleet on a different maintenance program revision because it came from another operator, and a repair station certificate meaning you also do customer work in the same hangar with the same technicians.

That last part is where suites strain hardest. An airline system assumes the aircraft is yours. A customer aircraft has a contract, a quoted workscope, an approval loop for non-routines above a threshold, customer-supplied parts, a different release statement and an invoice at the end. Running that through an airline module means shadow spreadsheets for the commercial side, which is why third-party revenue leaks.

What a custom build does: model the work order as either internal or customer from the start, with the customer variant carrying the quote, the approval threshold, the customer parts pool, and the billing rules. A non-routine above the threshold generates an approval request with photographs and estimated hours, and its clock is visible, because approval delay is a large hidden cause of turnaround overrun that nobody measures.

Problem 4: labour, parts and tooling do not meet until the invoice

Technicians clock to a job number. Parts are issued against a different reference. Tooling calibration status lives in another register. Contract labour arrives as an agency timesheet at month end. Reconciliation happens in accounting weeks after the aircraft left, and by then nobody remembers whether those eleven hours on the elevator were routine or a non-routine the customer agreed to pay for. The suites have materials and labour modules that connect inside a single-vendor deployment; the breakage is at the seams, meaning agency timesheets, a subcontracted NDT vendor, a part that returned under a different serial, a tool overdue for calibration when it was used.

What a custom build does: one work order object accumulating everything chargeable and everything airworthiness-relevant against the same task, with tool serial and calibration status validated at issue rather than at audit. Subcontracted work becomes a tracked line with its own certification expected back. The invoice becomes a report, not a reconstruction. This is where third-party MRO operations find money quickly, because the gap between what was done and what was billed is usually larger than anyone in the building believes.

Problem 5: legacy records, and the migration nobody scopes properly

Every one of these projects meets the same wall. Current fleet status is partly in the suite, partly in scanned PDFs from a previous operator, partly in a records room, and partly in a retired engineer's filing logic. Migrating that is not a data load, it is a reconciliation where somebody decides tail by tail and task by task what the truth is.

What a custom build does about it: scope the reconciliation as a real workstream with named engineers and a duration, and use document extraction properly. This is the one place a model earns its cost in an MRO project, reading thousands of scanned task cards, 8130-3 tags and maintenance releases to pull task references, dates, hours, cycles and part serials into candidate records an engineer confirms. It changes their job from typing to judging, which is where the throughput difference comes from.

What this costs and how long it takes

A targeted first release covering AD and SB status evaluation, hangar visit control with tablet-based non-routine capture, and labour and parts capture flowing to invoice runs $120,000 to $250,000 and ships in 16 to 24 weeks. A full platform covering planning, execution, materials, records and customer billing runs $400,000 to $1,200,000 across 12 to 24 months, and most operators should not attempt it in one move.

What drives cost up: the number of aircraft types and maintenance program variants. Regulatory scope, because satisfying both an FAA Part 121 program and an EASA Part-CAMO structure carries two sets of evidence requirements. Third-party work, which adds approvals and billing. Interfacing to a suite you are keeping. And records migration, the item most likely to be underestimated by a factor of three. What holds cost down: keeping the incumbent as system of record for what it does well, and building only the layer where your operation differs from the vendor's assumption.

Build versus buy, and the surround strategy we usually recommend

Buy if you operate a single type under a stable maintenance program, do no third-party work, and your records came to you clean. TRAX and Rusada ENVISION serve that operator well, and a build would spend eighteen months rebuilding something you can license. Buy AMOS or Maintenix if you are large enough to fund a proper implementation team and disciplined enough to change your processes to fit the product, which is the real precondition for those deployments succeeding.

Build when two or more of these are true. You run a mixed fleet where one subfleet always breaks the vendor's program structure. You do meaningful third-party Part 145 work in the same hangar as your own fleet and your invoicing is reconstructed after the fact. Your AD and SB compliance logic genuinely lives in spreadsheets that a named engineer maintains. Your heavy check overruns are driven by non-routine growth that nobody sees until the morning meeting. Or your records are a mix of inherited formats that the suite was never able to absorb.

The strategy that works most often is not replacement. It is surround: keep the suite for what it does adequately, build the layer where your operation is genuinely different, and integrate them properly. That is an unfashionable recommendation for an agency to make because it is smaller work, but it is the one that survives contact with a hangar.

How to choose a developer for aircraft maintenance software

Ask them to model AD applicability on a whiteboard. A developer who has done aviation work will ask about effectivity, embodied modification status, alternative methods of compliance and supersession before they draw anything. A developer who draws a task with a due date has built a maintenance scheduler for trucks.

Ask how they will handle the difference between an internal work order and a customer work order, and listen for whether approval thresholds and customer-supplied parts appear unprompted.

Ask what they have integrated, naming the specific system and interface: AMOS, Ramco, TRAX and Maintenix all expose data differently, and your ERP (Enterprise Resource Planning) and payroll sit on the other side of the labour question. Ask how they will approach records migration, and be suspicious of any answer that sounds fast. The right answer includes an extraction pass, a human confirmation workflow and a named engineering owner on your side.

Ask who owns the code and get it written down before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in any other firm. At Digital Heroes the client owns the code from the first commit. In aviation this matters more than usual, because the system becomes part of your compliance evidence and losing control of it is not a commercial inconvenience, it is an airworthiness problem.