Military MRO and Depot Maintenance Software: Why One Teardown Finding Re-Plans the Entire Line

Why the plan you inducted against stops being true in week two

An airframe comes in for a programmed depot visit against a package of roughly four thousand planned hours. Panels come off. Corrosion is found on a former that was not on anyone's list. A wiring harness is discovered to be a variant nobody in the shop has seen because this tail number came from a different lot. Two of the parts required are government furnished and are not on site. The technician qualified on that structural repair is on the other line, and the technical order for the repair was revised eleven weeks ago and the shop copy is the old revision.

Now everything re-plans at once: the schedule, the parts, the tooling, the certified labour, the contract forecast, and the record package that has to follow this specific tail number for the rest of its life. That is the defining characteristic of depot maintenance and it is why software built for scheduled fleet maintenance struggles here. An airline heavy check has variability. A depot induction has discovery as the main event.

The commercial consequence is direct. Availability is the customer's metric, the contract usually has dates attached to money, and an induction that slips cascades into fleet readiness. Meanwhile the work you discovered is billable only if you can prove it was outside the original scope, which means the evidence chain matters as much as the repair. In our experience with regulated maintenance operations, the single largest recoverable loss is not productivity. It is over-and-above work that was performed, was legitimate, and could not be substantiated cleanly enough to bill without a fight.

Problem 1: configuration is per serial number, and the fleet is not uniform

Two aircraft of the same model in the same hangar can differ by a decade of modifications, time compliance orders applied in different sequences, replacement components with their own life histories, and government unique fit that never existed on the commercial version. The task you are about to perform depends on which of those states this particular tail number is in.

Commercial fleet systems handle configuration and they handle it in the way an airline fleet needs: effectivity by model and modification status, with component life tracking. Where depots strain them is the volume of unique states, the fact that modification embodiment is often being decided during the visit rather than before it, and that the record of what was actually fitted has to be defensible for decades rather than until the next check.

What a custom execution layer does: treat the as-maintained configuration of the specific asset as the master object for the visit, with every task, part fitted, serial removed, and modification embodied recorded against it in an append only log. Effectivity checks run at task issue rather than at package build, so a task that no longer applies because a modification was embodied last Tuesday does not reach a technician. The output at the end of the visit is not a report, it is a configuration statement you can hand over.

Problem 2: over-and-above work has no fast path, and the fast path is the whole job

Discovery work at a depot follows the same route as discovery work anywhere: found, written up, engineered, estimated, approved, resourced, materialled, executed. The difference is that on a line with a fixed induction slot every hour in that route is an hour the asset sits in a bay.

What a custom build does: raise the finding at the aircraft or the hull with photographs, zone and station reference, and the affected configuration item, then move it through a queue with target response times and thresholds. Small items inside a value band move without waking a programme manager. Larger ones go up with the schedule impact already computed against the induction plan. Critically, the record retains the evidence: what was found, where, when, by whom, against which inspection requirement, with the images attached. That is what turns the eventual invoice from a negotiation into an attachment.

Estimating gets faster when the system surfaces what a comparable repair actually consumed on your own line rather than what a standard says it should take. This is the one place we would use a language model here: reading inspection write-ups and matching them to historic findings so the estimate starts from your own history. Approvals stay human, because in a contract environment an automated approval is an audit finding waiting to happen.

Problem 3: what the incumbents do well, and where a depot outgrows them

Be fair to them. IFS Maintenix is a genuinely strong fleet maintenance system with real configuration control and it is used across defense fleets for good reason. Ramco Aviation covers a broad footprint from line to shop and is competitively priced. Swiss AviationSoftware AMOS is excellent, and it is an airline product at heart, tuned for operators running scheduled checks. SAP will do anything you configure it to do, and the cost and speed of configuration is exactly the issue.

Four gaps show up consistently at depots and shipyards. Government furnished material and property accountability, because a part you do not own, sitting in your bonded store, with its own record obligations, is not the same object as a part you bought. Technical order and technical data currency, because performing to a superseded revision is a finding regardless of whether the repair was correct. Contract driven over-and-above evidence, because commercial MRO systems assume a work order and an invoice rather than a scope baseline and a claim. And the depot's own shop flow, which is not an airline check and looks more like a factory routing with back shops, plating, non-destructive test, and a paint queue that everybody competes for.

Our honest position: do not replace your fleet record system if you have a working one. Build the execution and re-planning layer around it and let the record system stay the record system. Rip and replace programmes at depots have a poor history and the reason is usually that nobody could afford to stop while it happened.

Problem 4: government furnished material stops lines and nobody owns the number

GFM arrives late, arrives wrong, or arrives and cannot be found. Because it is government property it carries accountability obligations of its own, and because it is free to the contractor it is often excluded from the inventory discipline applied to purchased parts. The result is a category of delay that is real, chronic, and structurally invisible in most systems, which then makes it hard to argue about at contract review.

What a custom build does: treat government property as a first class inventory class with its own record, ownership, condition code, and document trail, linked to the task waiting on it. Then produce the delay attribution report, because a line stopped for eleven days waiting on customer supplied material is a schedule fact that needs to exist in writing while it is happening, not be reconstructed afterwards from emails.

Problem 5: the record package is the deliverable, and it is assembled by hand

At the end of the visit, someone assembles the evidence: task sign-offs by qualified individuals, inspection buy-backs, non-destructive test reports, parts fitted with their certifications, modification records, weight and balance where applicable, deviations and their dispositions. A missing signature is an asset that cannot be released. In many depots this is a person with a checklist working through a paper package for weeks.

What a custom build does: capture the sign-off at the moment the task is performed, with the technician's certification validated at that moment rather than assumed, and the technical order revision recorded as part of the sign-off. Certification currency is checked when the task is issued, so a technician whose qualification lapsed last week cannot be assigned a task that requires it. The package then assembles from data you already hold. Build this offline capable, because hangar decks, dry docks and back shops have unreliable connectivity and any system that requires a live connection will be worked around with paper within a fortnight.

Maintenance records in a defense context are frequently controlled unclassified information, and the retention horizon is decades. That shapes the architecture: hosting inside a compliant boundary, access restricted to the right population, an append only audit trail, and an export format that will still be readable when the current system is long gone. Decide those in the first sprint rather than after a security review at the end.

What this costs and how long it takes

A depot execution layer covering serial level as-maintained configuration, task issue with certification and technical order currency checks, over-and-above capture with evidence, and rolling re-plan against the induction schedule runs $110,000 to $220,000 in 16 to 22 weeks. Adding government furnished material accountability, tooling and calibration control, back shop routing, record package assembly, contract milestone and earned value reporting, and integration with the fleet system of record runs $300,000 to $750,000 over 12 to 20 months.

Cost drivers particular to depots: the number of platforms, because a second airframe type is not a configuration exercise, it is a second data model conversation. Integration with government systems, which moves at the pace of the customer's approvals rather than yours. Offline capability, which roughly doubles the testing burden and is not optional. The compliant hosting boundary. And historical record migration, where decades of paper may need to be brought forward. What keeps cost down: one platform, one line, and the discovery to approval path first, because that is where the schedule and the money both live.

Build versus buy, honestly

Buy if you run a single platform, packages are largely predictable, over-and-above is a small share of your hours, and your customer is not imposing unusual property or data requirements. Configure Maintenix or Ramco properly and put the difference into tooling and people. Buy also if you have no maintenance system at all, because a commercial product will get you to a defensible baseline faster than a build will.

Build the execution layer when two or more of these are true. Discovery work is a large share of your hours and its approval path is measured in days. Your over-and-above billing is routinely disputed for lack of evidence. Government furnished material delays are chronic and unattributed. You run multiple platforms or a mixed aviation and marine portfolio that no single product fits. Or your record package assembly takes weeks of a person per asset.

How to choose a developer for depot maintenance software

Ask them what an as-maintained configuration is, and how it differs from a bill of materials. If those are the same thing to them, they will model your fleet as a product catalogue and you will discover the difference during the first modification.

Ask how they will handle offline. Hangar decks and dry docks are not offices. Any answer that assumes connectivity means paper will return and your data will be a month stale.

Ask how they intend to coexist with your existing fleet record system rather than replace it, and which direction data flows for each object. A developer who wants to replace everything is proposing a programme your customer will not tolerate a pause for.

Ask about the compliance boundary early: where production runs, who can access it, how support is brokered, and how the audit trail is protected from edit. If this is an afterthought in the proposal it will be a crisis in month nine.

Ask who owns the code, the repository and the hosting accounts, and get it in the contract before kickoff. At Digital Heroes the client owns it from the first commit. Depot records outlive contracts and vendors, so you need both the system and an export you can read in twenty years.