Migration integrity
Maintenance-data migration validation between record systems
Maintenance-data migration validation confirms that records moved from one maintenance system or operator to another carried across completely and unchanged. It is run by or for a lessor, airline, operator, or management company after an induction, an outsourcing change, or a system replacement loads a new dataset. It covers task and program parity, AD and SB status, component and life-limited part counters, due-date logic, and the document attachments behind each record. You receive a source-to-target validation, a register of every record that dropped, shifted, or detached during the move, and the evidence needed to reconcile the two datasets.
When this review is needed
- An aircraft was inducted and its records were loaded into the receiving party's system from a prior operator's export.
- A maintenance system was replaced and the entire fleet dataset was migrated between platforms.
- Records management moved to a new provider and the working dataset was transferred along with it.
- A migration is finished, the screens look populated, and no one has confirmed the new figures match the old ones.
- A due date or counter looks wrong after a transfer and the team needs to know whether the move introduced the error.
The problem
A migration looks successful when the new screens fill with data. Field mappings rarely line up one to one between systems, intervals and thresholds get reinterpreted, calendar and counter fields shift, and attachments either fail to follow or detach from the records they prove. Nothing on the surface flags a task that silently dropped or a due date that the target system recomputed differently, so the dataset is trusted long before anyone has compared it to where it came from.
What gets reviewed
- Record-count parity between the legacy export and the loaded target dataset
- Field mapping for tasks, intervals, thresholds, and repeat terms
- AD and SB status with method of compliance and accomplishment references preserved
- Component, calendar, and cycle counters checked source to target
- Life-limited part status and remaining-life figures across the move
- Due-date and next-due logic recomputed by the target system
- Attachments, scans, and links retained against the records they support
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
- Total tasks, components, and status lines reconcile between the source export and the target
- Each interval, threshold, and repeat term mapped to the correct target field without reinterpretation
- AD and SB status, method of compliance, and accomplishment references survived the move unchanged
- Counters and remaining-life figures match source to target within the expected utilization
- Next-due dates recomputed by the target system agree with the source basis
- Every migrated status line still links to its supporting attachment or scan
- No active task was dropped, duplicated, or superseded incorrectly during the load
Evidence normally required
- Legacy dataset export or the prior system's status reports
- Target system export after the migration completed
- Field-mapping specification used for the migration if one exists
- AD and SB status from both systems for comparison
- Component and life-limited part lists from source and target
- Sample of source attachments to confirm against the migrated links
Common discrepancies
- Active tasks present in the source export that did not load into the target
- An interval that mapped to the wrong target field and changed the next-due date
- AD method-of-compliance text truncated or lost during the field transfer
- Counters that imported against the wrong unit or reference and now drift
- Attachments that detached, so a migrated status has no document behind it
- Duplicated records created when a load was run more than once
- Life-limited part remaining life that disagrees between the two systems
What is at stake
A dataset that lost tasks or shifted intervals during a move drives planning and compliance off figures that no longer match the source. A counter that migrated wrong puts a component or a life-limited part at risk, and a detached attachment leaves a status with nothing behind it. Errors introduced in a migration are hard to find later because both systems show confident, populated screens.
How the work runs
Pin both datasets
Capture the legacy export and the post-migration target export as the two fixed sides of the comparison.
Check parity and mapping
Reconcile record counts and confirm each interval, term, and counter landed in the correct target field.
Trace status and attachments
Verify AD, SB, and life-limited part status survived the move and that each line still links to its supporting document.
Report and rank remediation
Deliver the discrepancy register with each dropped, shifted, or detached record ranked by compliance and counter impact.
What the buyer receives
- A source-to-target validation showing parity and every discrepancy by record
- A register of dropped, shifted, duplicated, and detached records with evidence
- A reconciliation of due dates and counters that the target recomputed differently
- A remediation list ranked by compliance and counter impact for the records team
Who uses the output
- Records teams correcting the target dataset before it is relied on
- Continuing-airworthiness staff confirming compliance status survived the move
- Asset and induction teams signing off that the transferred data is sound
How the work fits into the transaction or program
Validation runs after the load and before the new dataset becomes the working record, so a migration is trusted only once it has been compared to its source. It protects every later use of the data, from planning to a return that will read the migrated status.
Start with a single asset
Start with a single tail and expand once the workflow is proven.
Jurisdiction-specific considerations
A migration that crosses operators in different jurisdictions can carry status expressed against one authority's program structure into a system configured for another. The validation confirms that intervals, compliance terms, and required record fields still hold meaning under the receiving operator's basis rather than assuming the mapping is neutral.
Regulatory limits
Validation confirms that migrated data matches its source and flags where it does not. It does not certify the new system, approve the maintenance program in it, or make an airworthiness determination from the migrated data.
What this review does not cover
- Performing the migration or configuring the target system
- Re-creating source records that were never provided in the export
- Any airworthiness determination based on the migrated dataset
Specific to this review
- A migration is judged by source-to-target parity, not by whether the new screens look populated, because a populated screen can be missing tasks the source held.
- Field mappings between systems are rarely one to one, so an interval or compliance term can change meaning in transit without any error message.
- Attachments and links are validated separately from the status lines, since a record can migrate while the document that proves it stays behind.
Sources
U.S. Government (eCFR). Records an owner or operator must keep, including total time in service, current status of life-limited parts, and AD compliance.
U.S. Government (eCFR). Requirement to transfer maintenance records with an aircraft on sale or transfer of ownership.
Federal Aviation Administration. FAA acceptance criteria for electronic recordkeeping systems and electronic signatures.
Federal Aviation Administration. FAA guidance on making and keeping maintenance records and acceptable recordkeeping practices.
European Union / EASA. Continuing airworthiness, maintenance records, CAMO responsibilities, and the airworthiness review process in the EASA system.
Frequently asked questions
The migration finished and the screens are full. Why validate?
A populated screen only shows that something loaded, not that everything loaded correctly. Dropped tasks, remapped intervals, and detached attachments do not announce themselves, so the only way to know is to compare the target against the source export.
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.
Walk through your situation with an engineer who has done this work.