From paper to electronic records without losing history

The biggest worry when leaving paper behind is not the technology — it is the history. The aircraft has a few thousand hours behind it, a dozen binders, and a maintenance programme that has been revised three times. The question is: how much of that has to be transcribed for the electronic system to tell the truth?

The answer is less alarming than it sounds, provided you separate two things: historical records and current state.

What does not have to be transcribed

The aircraft’s flight history from new does not have to enter the system flight by flight. The paper log remains an archive — a record created in accordance with the rule, carrying signatures, and it does not stop being valid because it happens to be on paper. It continues to be retained and is transferred with the aircraft on a change of ownership.

What does have to be in the system for the arithmetic to work:

• the state of every counter on the go-live date,
• the maintenance programme in its current revision, with all tasks and their limits,
• the last accomplishment of every task — with date, counter state at the time of the work, and a reference to the release to service,
• life-limited components, with their state and installation date,
• the status of directives and bulletins,
• aircraft documents with expiry dates.

That is the whole scope. Not “everything”, but the starting point from which every due date can be computed correctly. Records older than that point stay where they are, subject to the retention periods required by ML.A.305(h).

One caveat: if reaching for the paper is a routine part of daily work — say, the installation history of an engine that has moved between aircraft — transcribe that too. Not because the rule demands it, but because otherwise the new system is 90 % complete, and 90 % is precisely the level at which people go back to the binder.

The opening balance: three files, one order

Loading the starting state is called the opening balance, and it has a forced order, because each step consumes the previous one:

1. Counters. The initial state of every counter. Without it nothing can be computed.
2. Tasks. The maintenance programme: task codes, hour, cycle and calendar limits, tolerances, and the “whichever comes first / later” rule.
3. Compliances. The last accomplishment of each task, with the reference point for the next due.

Four rules that save the most time:

• Do not author the files from scratch. The template should be generated by the system, containing the real counter and task codes of that specific aircraft. A hand-written file produces a round of corrections to names rather than to data.
• Always dry-run first. A well-built dry run shows item by item what will happen and writes nothing. That is the moment for reading, not for clicking “next”.
• Assumptions have to be announced. If a file has no planned due for the last accomplishment, the system must state plainly that it is taking the accomplishment date as the reference. That assumption decides the first due date after migration — it cannot be buried in code.
• Nothing may disappear quietly. Every unrecognised column and every skipped row has to appear in the report. An import that “completed without errors” while ignoring three rows is worse than one that failed.

Signing for the starting state

The counter balance is not a technical operation — it is a declaration about the state of the fleet. It should require a signature (in our system: re-entering your password) and a source reference in a form somebody can verify:

Paper techlog no. 3, page 41, state as at 2026-07-18

That single line is what allows the question “where did this number come from” to be answered two years later. Without it the starting state is a value with no provenance, and all subsequent arithmetic rests on nothing.

What the opening balance will not do

Three limits, better known in advance:

• A balance can only be loaded onto a counter with no history. A counter already in motion is adjusted by a correction with a stated reason, never by an import. Otherwise you would have built a mechanism for overwriting state — which is exactly what the whole record system is constructed to prevent.
• The same file loaded twice writes nothing. Idempotency is not a convenience but a safeguard: during a migration somebody will click twice.
• An import does not assess applicability. Directive and bulletin status is transcribed together with the organisation’s decisions, not merely with the numbers.

The dual-run: why, and for how long

Running the paper and the electronic log in parallel for an agreed period is not a lack of confidence in the system. It does three things at once: it lets people learn the new workflow without risk, it produces evidence for the authority, and it surfaces discrepancies earlier than the next airworthiness review would.

Rules to settle in writing before you start:

• Which register prevails in case of a discrepancy (during the dual-run, usually the paper one).
• How long — measured in flights or months, with an actual end date rather than “until further notice”.
• Who compares the registers, how often, and where the result of each comparison is recorded.
• What constitutes a stop signal for the rollout and a return to paper.

A dual-run reliably uncovers one thing no test finds: who actually fills in the log. If in practice one person does it in the evening on behalf of three pilots, an electronic system with named signatures exposes that immediately — which is valuable in itself, even when it is uncomfortable.

What to agree with your authority

The list is short, and it is better to have it ready before the first question arrives:

1. A description of the system: where the data comes from, who approves it, how record integrity is demonstrated, and what the procedure is while the system is unavailable.
2. The retention interpretation your organisation has adopted (ML.A.305(h)), split between detailed and summary records.
3. Agreement on the printed entry layout against the form the authority expects.
4. Recognition of the electronic signature as equivalent to a signature in the paper log — with a description of exactly what the signature covers.
5. The scope and end date of the dual-run.

What to expect: the conversation is rarely about whether an electronic log is permissible — the rule speaks of a record system, not of paper. It is about whether this particular system meets the conditions and whether the organisation can demonstrate it. Those are two different conversations and only the second one can be prepared for.

One point specific to operating across the EU: Part-ML is common to all Member States, but the practice of accepting a computerised record system sits with your national competent authority. Expect the substance to be identical and the procedure not to be — the format of the submission, the expected lead time and the depth of questions about backups vary. If you operate aircraft on more than one register, plan for one conversation per authority and do not assume the second will mirror the first.

A schedule that works

A realistic eight weeks for a fleet of a few aircraft:

Week	What happens
1	Inventory: what is on paper, what is missing, who has access
2	Aircraft and counter configuration; the system description for the authority
3–4	Opening balance: counters → tasks → compliances, with dry runs
4	Submission to the authority and handover of the system description
5–8	Dual-run, weekly register comparison, configuration fixes
8	Wrap-up and request to end the dual-run

Week one is the most frequently underrated and regularly turns out to be the most important. An inventory routinely exposes gaps that have been there for a long time — tasks with no recorded last accomplishment, components with no installation history, directives assessed but with no trace of the decision. The migration does not create them; it displays them. Assume up front that part of the rollout is not work on the system but clearing a backlog — and that it is time well spent, because the person conducting your next airworthiness review would look for exactly the same things.

The three most expensive mistakes

1. Migrating with no reference point for due dates. Transcribing accomplishment dates alone, without the counter state at the time of the work, produces a due list that looks right and is wrong. Fixing it means repeating the import.
2. Starting without deciding which register prevails. A dual-run without that rule ends with two registers of equal standing and an argument at the first discrepancy.
3. Rolling out “while we are at it” during an airworthiness review. Stacking the ARC deadline onto a data migration turns every migration problem into a deadline problem. The best moment to start is immediately after a review — that gives you eleven quiet months to close everything properly.