Skip to content

Post-migration assurance

Reconciling an operator's deferred maintenance log to source after migration

After a maintenance system change, scanning project, or re-indexing, an operator's deferred maintenance log may no longer trace to the tech log entries and work packages that created it. This reconciliation re-derives the deferral population from source, item by item, and compares it against what the migrated system now shows. Records and continuing-airworthiness staff run it once the new system is live and before the next audit or handover relies on the data. The operator receives a source-verified deferral history, a discrepancy register, and corrections routed to the right system owners.

When this review is needed

  • A new maintenance system went live and open deferrals were loaded from spreadsheets or automated extracts.
  • Paper tech logs were digitized and the deferral index was built by OCR rather than by review.
  • The open-items count changed across the cutover and no one can say which system was right.
  • An audit, ARC review, or lease event will read the deferral history within the next few months.

The problem

Deferral data is the most time-sensitive record an operator migrates: open items carry live rectification clocks. Cutover loads compress rich tech log entries into structured fields, and details like the applicable MEL sub-item, the raise timestamp, or the accumulated interval get truncated, defaulted, or mapped wrong. The operator then controls live deferrals against data that quietly differs from the certified entries behind it.

What gets reviewed

  • Open deferrals verified against their originating tech log entries and current clock positions
  • Cleared items sampled or fully traced to clearing entries and corrective-action evidence
  • MEL and CDL references, categories, and intervals as loaded versus as certified at source
  • Cutover load files compared against the pre-migration system's final state
  • Deferral-linked scheduled tasks and alerts functioning in the new system

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Send a representative, redacted record set and we will scope the review.

What gets validated

  • Every open item in the new system matches a certified tech log raise with the same defect, date, and MEL basis
  • Rectification clocks compute from the certified raise data, never from load-file defaults
  • No item open in the old system's final state is absent from the new one, and no phantom items were created in the load
  • Cleared-item records retain their clearing entry references after migration
  • System alerts and due-list logic trigger correctly for migrated deferrals approaching their limits

Evidence normally required

  • The migrated deferral log and the cutover load files
  • The pre-migration system's closing export or final reports
  • Tech log records covering open items and the sampled cleared population
  • MEL and CDL revisions relevant to the migrated items
  • Work packages containing clearing actions for the sampled closures

Common discrepancies

  • Interval clocks restarted at the migration date, silently granting extra time on open items
  • MEL sub-item references truncated by field-length limits, changing the applicable category
  • Items cleared in the legacy system reappearing as open after the load
  • Raise timestamps defaulted to midnight or to the load date, corrupting interval arithmetic

What is at stake

A wrong interval start date in the migrated record can let an open deferral run past its true limit while the system shows margin, which turns a data defect into an airworthiness event. Historical distortions surface later, during audits or lease returns, where a log that disagrees with its own tech logs undermines every other migrated record class.

Move from findings to resolution

Move from findings to a documented resolution path.

How the work runs

01

Capture both states

Secure the legacy system's closing state and the new system's post-load state before either drifts.

02

Verify live items first

Trace every open deferral to its certified raise and correct clocks immediately.

03

Trace the history

Reconcile cleared items by full trace or defensible sample against tech logs and work packages.

04

Route corrections

Hand discrepancies to system owners with evidence attached, and document the assurance for audit.

What the buyer receives

  • A source-verified deferral history annotated item by item
  • A discrepancy register split between urgent open-item corrections and historical fixes
  • A load-defect analysis the operator can use to test other migrated record classes

Who uses the output

  • Maintenance control correcting live deferral data before a limit is missed
  • Continuing-airworthiness managers documenting migration assurance for the authority
  • Records leadership deciding whether other migrated data needs the same treatment

How the work fits into the transaction or program

Deferral reconciliation is usually the first and most urgent piece of post-migration records assurance because it protects live rectification limits. Its defect analysis then calibrates how deeply the operator must verify slower-moving record classes like AD status and component times.

Jurisdiction-specific considerations

EASA operators need migrated deferral data to survive the airworthiness review under Regulation 1321/2014, and several national authorities ask explicitly for data-migration assurance evidence after a system change. FAA operators carry the same substance through 14 CFR 91.417 recordkeeping and MEL management. ICAO Annex 6 based frameworks in third countries add their own deferred-defect reporting expectations for transferred aircraft.

Regulatory limits

The reconciliation validates data against certified source entries. It does not authorize continued deferral of any item, extend intervals, amend the MEL, or make airworthiness determinations. Corrections to live records are executed by the operator's authorized staff under its own procedures.

What this review does not cover

  • Rectification of the underlying defects
  • Maintenance system configuration or interface repair
  • MEL development or revision services

Specific to this review

  • Open deferrals deserve verification within days of cutover, since every operating day on a wrong clock consumes real margin.
  • Field truncation is subtler than data loss: a reference shortened by two characters can point to a different MEL sub-item with a longer interval.
  • The final report run of the legacy system is the single most valuable reconciliation input, and it is unrecoverable once the old platform is decommissioned.
  • Phantom open items created by a bad load waste maintenance control attention and hide real items in the noise, so both directions of mismatch matter.

Sources

Frequently asked questions

Should we reconcile every historical deferral or sample?

Open items always get full verification. For history, sample first: if the load-defect rate in the sample is near zero, a documented sample can be defensible; if defects appear, expand to full trace, because migration errors are systematic rather than random.

Relevant glossary terms

Related pages

Where this fits

Talk to an engineer who has done this work

We will walk through your current state, the records or evidence involved, and a scoped first engagement.

Talk through the aircraft, records, evidence, deadline, and next useful step.