The first thing to understand about moving statutory record books to digital is that you do not migrate them. A paper Oil Record Book is a legal document with signed entries; it does not become the opening pages of an electronic one. You close it, you open a new one, and you keep the old one aboard for as long as the applicable Annex requires. The second thing is that software type approval is not the same as being allowed to use the system on your ship. The chain has two stages and a document at the end of it: the software is type approved against IMO Resolution MEPC.312(74) by the flag Administration or a recognised organisation where authorised by flag, an installation survey is carried out on board, and a ship-specific Declaration of MARPOL Electronic Record Book is issued confirming the installation meets the guidelines. That Declaration must be kept aboard, and during a MARPOL survey or a Port State Control inspection its absence means the electronic record book and the records it holds are not accepted. Operators who assume a vendor's type approval covers their vessel discover this at the worst possible moment. Start a free trial of Marine Inspection and understand the chain before starting the project.
Stage 1
Type approval of the software
The application is approved against the IMO Guidelines for the Use of Electronic Record Books under MARPOL, adopted as Resolution MEPC.312(74). Carried out by the flag Administration, or by a recognised organisation where authorised by flag. This is the vendor's obligation, not yours.
Stage 2
Installation survey on board
A survey of the actual installation on the actual vessel. Type approval says the software can meet the guidelines; the installation survey establishes that this deployment on this ship does. This is yours to arrange, per vessel.
Stage 3
The ship-specific Declaration
A Declaration of MARPOL Electronic Record Book confirming the installation meets the requirements of the IMO guidelines, issued by the flag Administration or by an authorised organisation following the installation survey. It must be carried on board. Without it, during a MARPOL survey or a Port State Control inspection, the electronic record book and its records are not accepted.
Every project failure in this area traces back to treating stage one as the whole chain. A vendor's approvals database entry tells you the software is capable of compliance. It says nothing about whether your ship is permitted to rely on it, and the difference is a survey and a certificate per hull.
You Close the Book. You Do Not Convert It.
This is the conceptual point that makes the rest of the project straightforward, and getting it wrong creates work that should not exist. Book a Marine Inspection demo and plan the cutover rather than a data migration.
What does not happen
Historical entries are not typed into the new system, scanned into it, or otherwise carried forward as records. A signed paper entry is evidence of what was recorded and by whom at the time; a retyped copy of it is not the same document and does not become one by being stored somewhere newer.
No conversion, no back-entry, no scanning as records
What does happen
The paper book is closed at a defined moment with a final entry, the electronic book opens from that point forward, and both are held — the electronic one in use, the paper one retained aboard for the period the applicable requirements demand, available for inspection throughout.
Clean boundary, both books retained, continuity demonstrable
Why scanning still has a place
Scanning the closed paper book is useful for internal access, superintendent review and searchability, and there is no reason not to do it. What matters is that the scan is a convenience copy rather than the record — the paper remains the document, and it stays where the regulations say it stays.
Scan for access, retain the original as the record
What this simplifies
Almost everything. There is no data mapping exercise, no field reconciliation, no history import to validate. The project becomes an approval exercise and a change of practice on a defined date rather than a data migration — which is why logbook transitions succeed far more often than maintenance system migrations do.
An approval project, not a data project
Two Tracks, Different Rules
The books on a vessel do not all follow the same approval regime, and treating them as one project is the second common error. Sign up for Marine Inspection and separate the two tracks before scoping anything.
Track one: MARPOL record books
Governed by MEPC.312(74) and the associated amendments
Oil Record Book, Parts I and II, under Annex I regulations 17.1 and 36.1
Cargo Record Book under Annex II regulation 15.1
Garbage Record Book, Parts I and II, under Annex V regulation 10.3
Ozone-depleting Substances Record Book
Recording requirements under the NOx Technical Code
Requires: type approval, installation survey, and a Declaration carried on board
Track two: everything else
Governed by flag requirements and, where applicable, SOLAS
Deck log and engine log
GMDSS radio log
Ballast water record book
Bridge logbook, crew roll and other operational records
Non-statutory internal records and checklists
Requires: whatever your flag says, which varies considerably and is frequently lighter
The second track is where flag variation becomes most visible. Administrations have addressed these separately and at different times — one published a technical advisory notice specifically for SOLAS electronic log books, another issued guidance covering both statutory and non-statutory records with its own system requirements and approval processes, and a third permits voluntary use across a list that includes the bridge logbook and crew roll alongside the oil record book. Two vessels under different flags can therefore have quite different scope for the same project.
Ask your flag which books, in what form, and under whose approval — before you scope
Administrations differ on which record books they accept electronically, who may approve a system on their behalf, what the installation survey involves, and whether combined electronic and hard copy record keeping is permitted during a transition. At least one administration has published guidance addressing that combined arrangement directly. All of that is answerable with one enquiry and none of it is answerable by reading a vendor's website.
The Specification a System Has to Meet
The guidelines set out requirements that are unusually testable, which makes them a useful evaluation checklist rather than only a compliance one. Schedule a walkthrough and put any candidate system through each of these.
Tamper evidence
The system must be able to automatically record revisions and attempts to manipulate data. Not prevent them in every case — record them, so that an inspector can see what was changed and what was attempted.
Access control
Role-based access control, so that entries are attributable and the ability to make or amend them is governed rather than shared. This is also the practical mechanism by which an entry carries a name.
Resilience
Data recovery and power source standards that must be considered in approval. A record book that loses entries in a blackout is not a record book, and the guidelines treat this as a design requirement rather than an operational hope.
Printing
To accommodate port State inspections, systems should be capable of printing out entries, individual pages or the entire log — along with the name of the person who made each entry, a record of amendments, the date and time of printing, page counts, and the name and version of the system used. This is the single most testable requirement in the guidelines and it is exactly what an inspector will ask for.
Test the printing requirement during evaluation rather than during an inspection. Ask the vendor to produce a printed extract from a populated system and check every element against the list above — the person named against each entry, the amendment record, the timestamp of printing, the pagination, and the system name and version on the output. A system that prints a clean-looking log without those elements has not met the specification, and the gap will only ever surface in front of somebody official.
The Cutover, Per Vessel
Sequenced per ship rather than fleet-wide, because the Declaration is issued per installation and the installation survey happens where the vessel is. Start a free trial and let the crew work the system before the survey rather than after it.
1
Confirm scope with flag
Which books, under whose approval, what the installation survey involves, and the position on combined paper and electronic keeping during transition. Get it in writing and keep it with the project file.
2
Verify the software's approval status
Type approval against the guidelines, and specifically whether it is recognised by your flag or by an organisation your flag authorises. Approvals databases are published; check the entry rather than the marketing claim.
3
Install and let the crew practise
Run the system in parallel with the paper book before the survey, so that entries are being made competently by the time anybody assesses the installation. A crew learning the interface during a survey is an avoidable problem.
4
Installation survey and Declaration
Arranged with the flag Administration or the authorised organisation, resulting in the ship-specific Declaration. Nothing goes live as the statutory record until this exists and is aboard.
5
Close the paper book
A final entry at a defined moment, with the date and time recorded, so the boundary between the two books is unambiguous. The first electronic entry follows it directly, and together they demonstrate continuity.
6
Retain the paper aboard
For the period the applicable requirements demand, available for inspection, in a known location that the master and chief engineer can point to. Scan it for internal access if useful, but the physical book stays.
Per vessel
Six steps, repeated per hull, with an installation survey and a Declaration at the centre of each. There is no fleet-wide switch-on date in this project — there is a schedule of vessels, each with its own survey and its own boundary entry.
What Goes Wrong
Nine recurring failures, each avoidable and most of them avoidable cheaply. Book a walkthrough and check the project plan against them before starting.
Table 1: Recurring Failures in Logbook Transitions
| Failure | What happens | When it surfaces | The prevention |
|---|---|---|---|
| Type approval assumed sufficient | The system is in use as the statutory record with no ship-specific Declaration aboard | At a MARPOL survey or Port State Control inspection | Treat the Declaration as the go-live gate, per vessel |
| Historical entries retyped | Effort spent creating a copy that is not the record, and a paper book still required anyway | During the project, as wasted time | Close and open; never convert |
| Paper disposed of | The retained record is gone before its required period has run | When somebody asks for an entry from before the cutover | Define the retention position in writing before anything is moved |
| Ambiguous boundary | No clear final paper entry, so the join between the two books cannot be demonstrated | At the first inspection that spans the date | A dated, timed final entry, and a first electronic entry that follows it |
| Wrong books in scope | Books included that the flag has not accepted electronically, or excluded that it has | At approval, or later at inspection | Confirm the accepted list with your own flag in writing |
| Printing untested | The printed output lacks the name per entry, amendment record, timestamp, pagination or system version | When an inspector asks for a printout | Test printing against the guideline elements during evaluation |
| Crew untrained at survey | The installation is assessed while the people using it are still learning | At the installation survey | Run in parallel with paper before the survey, not after |
| Fleet-wide date assumed | A single go-live announced for vessels that each need their own survey | As soon as the first survey cannot be scheduled | Plan a vessel schedule, not a project date |
| Hybrid position unclear | Some books electronic, some paper, and no documented statement of which is which | At inspection, as confusion that reads as disorganisation | Confirm your flag's position on combined record keeping and document it aboard |
Questions to Put to Flag and Vendor
The first four go to your Administration and the rest to whoever is supplying the system. None of them takes long and all of them change the plan. Start a free trial and put the vendor questions to any candidate including this one.
Table 2: Questions Before Starting
| Ask | The question | Why it changes the plan | What a weak answer means |
|---|---|---|---|
| Flag | Which record books do you accept in electronic form? | Defines the scope of the whole project | Working from another flag's list, which does not transfer |
| Flag | Who may approve a system and issue the Declaration on your behalf? | Determines who you contact and how long it takes | Assuming any recognised organisation will do |
| Flag | What does the installation survey involve, and how is it scheduled? | Drives the per-vessel timeline more than anything else | Planning a rollout with no survey slots identified |
| Flag | What is your position on combined electronic and hard copy keeping? | Determines whether a phased transition is available to you | Assuming a hybrid state is acceptable without confirming it |
| Vendor | Show me the type approval entry, not the claim | Approvals are published and checkable | A logo where a database entry should be |
| Vendor | Print a populated log and let me check every guideline element | The most testable requirement there is | Reluctance, or output missing the name, amendments or version |
| Vendor | Show me the amendment record on an entry that was changed | Tamper evidence is a specification requirement, not a feature | A system where changes leave no visible trace |
| Vendor | What happens to entries during a power failure or a sync gap? | Data recovery and power standards are part of approval | An answer about the cloud, on a vessel that has no connectivity |
| Vendor | How many installation surveys have you supported, and with which flags? | Experience with your specific Administration shortens everything | Type approval without any installation history behind it |
IMPORTANT: CONFIRM EVERYTHING WITH YOUR FLAG
Requirements vary substantially by Administration and this page describes the general framework rather than your obligations. Flag States have addressed electronic record books at different times and with different scope — some by technical notice covering MARPOL books, some by separate guidance for SOLAS electronic log books, some covering statutory and non-statutory records together, and some permitting voluntary use across a defined list. Which books you may keep electronically, who may approve the system, what the installation survey involves and whether combined paper and electronic keeping is permitted are all questions for your own Administration. Retention periods are set by the applicable instrument and are not described here. Establish the required retention for each closed paper book with your flag or your technical adviser before disposing of anything — this page's advice is simply to retain until you have confirmed. The Declaration is the operative document at inspection. Where it is absent, the electronic record book and its records may not be accepted during a MARPOL survey or Port State Control inspection, regardless of the software's type approval status. Nothing here is legal advice.
Frequently Asked Questions
Do we transfer our existing paper entries into the digital system?
No. A statutory record book is not migrated — it is closed and a new one opened. Signed paper entries are the record of what was written and by whom at the time, and retyping or scanning them does not create an equivalent document. The correct sequence is a final dated entry in the paper book, a first entry in the electronic book following it, and retention of the paper aboard for the period the applicable requirements demand. Scanning the closed book for internal access and searchability is worth doing and entirely separate — the scan is a convenience copy, the paper remains the record.
Is type approval of the software enough?
No, and this is the most consequential misunderstanding in the whole area. Type approval establishes that the software can meet the IMO Guidelines for the Use of Electronic Record Books under MARPOL, adopted as Resolution MEPC.312(74). Using it as the statutory record on a specific ship additionally requires an installation survey on board and a ship-specific Declaration of MARPOL Electronic Record Book confirming that installation meets the guidelines. The Declaration must be carried aboard, and during a MARPOL survey or Port State Control inspection its absence means the electronic record book and the records it contains are not accepted.
Which record books does the MARPOL framework cover?
The guidelines apply to the Oil Record Book Parts I and II under Annex I regulations 17.1 and 36.1, the Cargo Record Book under Annex II regulation 15.1, the Garbage Record Book Parts I and II under Annex V regulation 10.3, the Ozone-depleting Substances Record Book, and recording requirements under the NOx Technical Code. Books outside that list — deck and engine logs, the GMDSS radio log, ballast water records, bridge logbook and operational records — follow flag requirements and, where applicable, SOLAS, which several Administrations have addressed separately and on different timelines. Treating both groups as one project is a common scoping error.
What must the system be able to do?
The guidelines specify software standards including the ability to automatically record revisions and attempts to manipulate data, role-based access control, and data recovery and power source standards. The most testable requirement concerns printing: to accommodate port State inspections, systems should be capable of printing out entries, pages or the entire log along with the name of the person who made each entry, a record of amendments, the date and time of printing, page counts, and the name and version of the system. Ask a vendor to produce a printed extract from a populated system during evaluation and check every one of those elements against the output.
Can we run paper and electronic side by side during the transition?
Possibly, and it is a question for your flag rather than a general answer. At least one Administration has published guidance that addresses the use of combined electronic and hard copy record keeping directly, alongside detail on which record books may be accepted in electronic format and which organisations may approve and accept systems on its behalf. Because Administrations have approached this differently and at different times, the availability of a hybrid state during transition varies — confirm it in writing, and if a combined arrangement is permitted, document aboard which books are kept in which form so that an inspector is not left to work it out.
Should this be a fleet-wide switch-on?
It cannot be, because the Declaration is issued per installation and the installation survey happens where the vessel is. The project is a schedule of ships rather than a date, each with its own survey, its own Declaration and its own boundary entry closing the paper book. The practical sequence per vessel is to confirm scope with flag, verify the software's approval status against the published approvals record rather than the vendor's claim, install and let the crew practise in parallel with paper, arrange the installation survey and obtain the Declaration, close the paper book with a dated final entry, and retain that book aboard for its required period.
The gate, per vessel
Nothing Goes Live Until the Declaration Is Aboard
Confirm with your flag which books, under whose approval, with what survey and what position on combined keeping. Verify the software's type approval in the published record rather than in a brochure. Let the crew work the system in parallel before anybody assesses it. Then close the paper book with a dated final entry, open the electronic one from that moment, and keep the paper aboard until you have confirmed how long it must stay. Six steps, per hull — and no data migration anywhere in them, which is why this project succeeds far more often than the ones that look similar.
