Every serious data migration outside shipping reconciles against a financial anchor. The cutover checklist for an ERP migration says: perform record count checks against baseline, run financial tie-outs on the trial balance and receivables and payables totals, confirm inventory valuation and aging reports match, spot-check a sample of transactions, and present the reconciliation evidence to business leaders. Those tie-outs are what make a migration provable — a balance either matches or it does not, and no amount of confidence substitutes for the number. A vessel maintenance migration has none of that. There is no trial balance for an equipment register, no aging report for a job history, and no financial total that proves the running hours landed correctly. So maritime projects tend to validate by opening the new system, looking at it, and agreeing it seems right. That is not validation, and it is why migrations that were declared successful produce jobs falling due at the wrong time three months later. The discipline is available and it transfers cleanly; it just needs a different anchor. This page sets out what to reconcile against instead, object by object. Start a free trial of Marine Inspection and build a target you can test against before you commit any data to it.
What every other industry reconciles against
Trial balance. Receivables and payables totals. Inventory valuation. Aging reports. Numbers that either tie out or do not, presented as evidence rather than as reassurance.
What a vessel migration has instead
Nothing equivalent, unless you build it. Which is why so many maritime migrations are signed off on the basis that the screens look populated.
The four anchors that do work
1Record counts, per object, per vessel — never at fleet level
2The next ninety days of due jobs, matched between old and new
3Open items — defects, deferrals, class conditions — matched exactly
4Twelve months of certificate and survey expiries, matched
The Due-Date List Is Your Trial Balance
Of the four anchors, this is the one that proves the most, because it depends on three separate objects having landed correctly at once. Book a Marine Inspection demo and produce the same ninety-day list from both systems before signing anything off.
What it tests
A job appears in a ninety-day due list only if the equipment exists in the right place, the job is attached to it with the right interval, and the counter or last-done date is correct. Three objects, one output. If the lists match, all three landed. If they do not, something structural is wrong even where record counts are identical.
How to run it
Freeze the source at a fixed moment, generate the ninety-day due list from it, generate the same list from the target, and compare line by line rather than by total. A count that matches with different jobs in it is the most dangerous possible result, because it looks like success.
Why ninety days
Long enough to include annual and quarterly intervals rather than only frequent ones, short enough that the list is a size a person can actually read. Run thirty and three hundred and sixty-five as well if you want, but ninety is the one that catches interval and counter errors while remaining reviewable by the chief engineer whose vessel it is.
Three Tiers of Validation, Translated
Migration practice distinguishes technical, business and process validation, and all three transfer to a fleet with specific maritime meanings. Sign up for Marine Inspection and plan for all three rather than only the first.
Tier 1
Technical: did the data arrive intact
Record counts, checksums and schema constraints in general practice. In a fleet: counts per object per vessel, field-level comparison on a sample, and attachment counts and total volume, since attachments are the object most often silently dropped.
Proves: nothing was lost in transit
Tier 2
Business: does it mean the same thing
Sample-based checks, reconciliations and report comparison. In a fleet: the four anchors above, plus spot-checking a sample of completed jobs to confirm the measured values, dates and attribution came across rather than only the completion flags.
Proves: the data says what it said before
Tier 3
Process: can the ship actually work
Can the business run key workflows using the migrated data. In a fleet: can a second engineer open a due job, complete it with a measured value and close it; can a finding become a work order; can a superintendent retrieve a component history. Tier three is the one maritime projects skip and the one that determines whether anybody uses the system.
Proves: the migration produced a working vessel, not a populated database
A useful formulation from general migration practice: if testing is rushed, the business will test it for you in production, and they are extremely thorough when they are angry. On a vessel that testing happens at three in the morning when a job that should have been scheduled was not, and the person doing it has no route to escalate until the office opens in another time zone.
The verification maritime has that no other industry does
You can walk to the equipment. Pick ten assets at random from the migrated register — across different systems and different levels of the hierarchy — go and find them physically, and check that the record matches the plate: identification, rating, location, and whether the thing described actually exists in that configuration. No ERP migration can do this. It takes an hour, it catches the errors sampling misses, and a chief engineer will find problems in that hour that a data team would not find in a week.
The Object-by-Object Checklist
Work through this per vessel rather than per fleet, and record the result. The right-hand column is the check that actually proves the row, as distinct from confirming that something arrived. Schedule a walkthrough and use this as the acceptance document.
Table 1: Migration Checklist by Object
| Object | What must arrive | The check that proves it | The failure it catches |
|---|---|---|---|
| Vessel register | Every vessel in scope, with particulars, flag, class and identifiers | Count matches, and each vessel opens with its own equipment beneath it | A vessel present as a heading with nothing attached |
| Equipment hierarchy | Component-level structure, consistent across vessels | Count per vessel, plus depth check — does the tree go as deep as the source | Flattening, where sub-components collapse into their parent |
| Asset identifiers | Serial numbers, makers, models, ratings, locations | Field-level comparison on a sample, then physical verification on ten assets | Identifiers dropped because the target field was named differently |
| Job definitions | Every planned job with its interval, counter type and acceptance criteria | Count per vessel, and the ninety-day due list matching line by line | Intervals arriving as the right number against the wrong counter |
| Running hours | Current counter value per unit, at a stated moment | Compare target values against the machines, not only against the source | Counters that were already wrong in the source and are now wrong in two places |
| Maintenance history | Completions with dates, measured values, condition found and attribution | Sample twenty closed jobs and read them, not just count them | Completion flags arriving without the values that made them useful |
| Open defects | Every open item with priority, owner and age | Exact match, item by item — this list is short enough to check completely | Open items silently closed by a status mapping rule |
| Deferrals | Deferred work with the reason and the dependency | Exact match, and confirm the reason text survived rather than a code | Deferrals arriving as overdue, or disappearing entirely |
| Certificates and surveys | Current certificates, expiry dates, survey positions and class conditions | Twelve-month expiry list matched between systems, line by line | Dates transposed between formats, which is common and hard to spot |
| Spares and inventory | Part records, quantities, locations, minimum levels | Count, plus the part-to-equipment link tested on a sample | Parts arriving as an orphaned list with no equipment relationship |
| Attachments | Drawings, manuals, photographs and certificates against their records | Count and total volume, plus opening twenty at random | Files migrated but unlinked, or links pointing at nothing |
| People and roles | Crew accounts with the right access and the right vessel | Have an actual crew member log in and try to do their job | Everyone technically present and nobody able to complete a task |
Count it per vessel. A fleet total of forty-seven thousand assets can be correct while vessel nine has none of them.
Decide the Rollback Trigger as a Number
General migration practice treats this as mandatory and maritime projects almost never do it. The value is not the rollback itself — it is that agreeing the number forces everyone to define what success means before anyone is emotionally committed. Start a free trial and agree the criteria while the decision is still abstract.
What the discipline says
Teams invest weeks planning the migration forward and no time planning what happens if it fails — and something always breaks during cutover. A rollback plan is described as not optional: script the procedure, test it, ensure backups are current and restorable, and define the decision criteria for triggering it before the cutover begins.
What a trigger looks like
A stated threshold agreed in advance — for example, that if more than a defined percentage of records are unmatched after cutover, the vessel reverts to the previous system until it is fixed. The specific percentage matters less than the fact that it exists and that somebody named can call it.
The maritime version
Reverting is easier here than in most industries, because the previous system is usually still installed and the vessel is one of many. A single ship going back to the old system for a fortnight while a mapping error is corrected is an inconvenience. Twelve vessels discovering the same error after cutover is a different situation entirely.
Keep the path open for weeks, not hours
Guidance in comparable migrations is to keep rollback scripts and previous-state snapshots active until the migration is validated, and to hold the rollback path open for the first two to four weeks. On a vessel that window should span at least one full maintenance cycle, because interval errors only become visible when a job either arrives or fails to.
Dry Run, Then Do It Again
The single highest-value practice in general migration work, and the one most often compressed out of a maritime schedule. Book a walkthrough and insist on at least two full rehearsals before the first vessel cuts over.
Run it complete
Execute the full migration against a staging environment using production-volume data rather than a sample. Validate the results against your acceptance criteria, fix what failed, and run it again — repeating until the dry run passes cleanly. A rehearsal that was not run end to end has not rehearsed the part where things break.
Test against the source
Compare outputs to the legacy system rather than to the new system's own view of itself. If the same report produces different results from the two platforms, the migration is not complete, regardless of how internally consistent the target looks.
Time the load
Performance testing asks whether the load can complete inside the available cutover window. In a fleet the window is a port call or a quiet period rather than a weekend, so a migration that takes eleven hours may not fit where a six-hour one would.
Write the runbook
The production migration should follow a tested sequence step by step, with validation at each stage before proceeding to the next, rather than a single load followed by a hopeful look. Document the mappings, the validation results, the error logs and the sign-offs — that documentation is what supports an audit later and what lets somebody else repeat the exercise on vessel two.
Cutover day
Freeze the source first
Set the legacy system to read-only, take final backups and snapshots, disable any interfaces, then run the final load. Without a freeze, entries made in the source during the migration window are silently lost — and on a vessel the person making them has no way of knowing a cutover is in progress unless somebody told the ship. Which is itself a step worth putting in the runbook.
The Period After Cutover
General practice calls it hypercare and treats it as a planned phase with named people. Maritime projects tend to call it going live and hope for the best. Start a free trial and plan the fortnight after the switch as deliberately as the fortnight before.
What it is
An intensive support period immediately after go-live with heightened staffing, rapid triage of issues, close monitoring and quick fixes for the data and workflow problems that surface once real users hit the system at scale. The migration is not done when the switch is flipped — it is done when the operation is stable on the new system.
Why maritime makes it harder
The people who will find the problems are at sea, in a time zone that may not overlap with anybody who can help, doing the job while they find them. Support availability during the first fortnight has to be defined in hours the vessel actually works rather than in office hours ashore.
Keep the old system readable
Retain the previous system in read-only form for reference rather than switching it off to save cost. Somebody will need to check what a record looked like before, and the ability to answer that question is worth more during the first weeks than any licence saving.
Then do a post-mortem
Before vessel two. Identify what the mapping got wrong, what the checklist missed, what took longer than planned and what the crew struggled with, and revise the runbook accordingly. On a fleet migration the first vessel exists to improve the second, and a project that does not capture those lessons repeats the same errors eleven more times.
Questions to Settle Before Any Data Moves
Each of these should have a documented answer with a name against it before extraction begins. Schedule a demo and ask them of whoever is running the migration, including us.
Table 2: Pre-Migration Decisions and Who Owns Them
| Question | Why it must be answered first | Who owns it | What no answer produces |
|---|---|---|---|
| What are the acceptance criteria? | Without them, sign-off is an opinion | You, with the vendor confirming they are testable | A migration declared successful by whoever is most tired |
| What is the rollback trigger? | It has to be agreed before anyone is committed | You, named, with authority to call it | Pressing on through a failed cutover because reverting feels like defeat |
| How many dry runs? | Two minimum, more if the first one fails badly | Shared, but scheduled by you | The production run being the first complete rehearsal |
| What is the cutover window per vessel? | The load has to fit inside a port call or quiet period | You, from the vessel schedule | A migration that overruns into working hours |
| Who freezes the source, and when? | Entries made during the window are otherwise lost | Shared, communicated to the vessel | Missing entries nobody notices for months |
| Who validates, per object? | Technical checks and business checks need different people | You for business and process, vendor for technical | Everything validated by whoever built it |
| Who walks the ship? | Physical verification needs somebody who knows the machinery | The chief engineer of the pilot vessel | The strongest available check going unused |
| What support exists in week one? | Problems concentrate in the first hours and days | Vendor, in writing, in the vessel's working hours | A crew abandoning the system in week one and never returning |
| How long does the source stay readable? | Reference access and retention obligations both need it | You, against your retention requirements | The old system switched off before somebody needed it |
MIGRATION VALIDATION REALITY
The validation practices described here are drawn from general enterprise data migration guidance published in 2026 rather than from maritime-specific standards. Reconciliation by record count and checksum, three-tier technical, business and process validation, dry runs against production-volume data, quantified rollback criteria and post-cutover hypercare are established practice in ERP, data warehouse and healthcare records migrations. The maritime translations offered — the ninety-day due list as a tie-out anchor, per-vessel counting, and physical verification against the machinery — are our own application of that discipline rather than a published methodology. Rollback thresholds are illustrative. The specific percentage cited in general guidance is an example rather than a standard; the value of the practice lies in agreeing a number in advance, not in any particular number. Retention obligations govern how long the source must remain accessible, and they are separate from any reference-access decision. Confirm them before decommissioning anything. This page is published by a software vendor, and the questions in the final table are ones we should be asked as readily as anybody else.
Frequently Asked Questions
What do you reconcile a vessel migration against?
Four anchors, since there is no financial tie-out available. Record counts per object per vessel rather than at fleet level. The next ninety days of due jobs, compared line by line between the source and the target. Open items — defects, deferrals and outstanding class conditions — matched exactly, since those lists are short enough to check completely. And twelve months of certificate and survey expiries. The due-date list is the most valuable of the four because a job only appears in it if the equipment, the job definition with its interval, and the counter or last-done date have all landed correctly. Three objects, one testable output.
Why count per vessel rather than for the fleet?
Because a fleet total conceals exactly the failure you are looking for. Forty-seven thousand assets can arrive correctly in aggregate while one vessel has none of them, or while two vessels have each other's. The same applies to every object — job definitions, history, spares, attachments. Count per object per vessel, record the result, and treat any vessel whose numbers look unusual relative to its sisters as a finding rather than a rounding difference. It takes marginally longer than a fleet count and it is the difference between a check and a gesture.
What is the difference between technical and process validation?
Technical validation proves the data arrived — record counts, checksums, schema constraints, field-level comparison on samples. Business validation proves it still means the same thing — reconciliations and report comparisons against the source. Process validation asks whether the business can actually run its key workflows using the migrated data, and it is the tier maritime projects most often skip. In a fleet that means having a second engineer open a due job, complete it with a measured value and close it; having a finding become a work order; having a superintendent retrieve a component history. A database can pass tiers one and two and still fail to produce a working vessel.
What validation can maritime do that other industries cannot?
Walk to the equipment. Take ten assets at random from the migrated register, across different systems and different levels of the hierarchy, go and find them physically, and check the record against the plate — identification, rating, location, and whether the item described exists in that configuration at all. No ERP or data warehouse migration has this option, it takes about an hour, and a chief engineer will surface problems in that hour that a data team would not find in a week of sampling. It is the strongest single check available and it costs almost nothing.
Do we really need a rollback plan?
General migration guidance is unusually blunt on this: teams invest weeks planning the migration forward and no time planning what happens if it fails, something always breaks during cutover, and a rollback plan is not optional. Script the procedure, test it, confirm backups are current and restorable, and define the trigger before cutover begins — a stated threshold of unmatched records above which the vessel reverts. The real value is not the reversion; it is that agreeing a number forces everyone to define success while the decision is still abstract and nobody is invested in declaring victory. Keep the path open for weeks rather than hours, ideally spanning a full maintenance cycle.
What happens immediately after cutover?
A planned support period rather than a hope. General practice calls it hypercare — heightened staffing, rapid triage, close monitoring and quick fixes for the problems that surface once real users hit the system at scale, on the principle that a migration is done when the organisation is stable rather than when the switch is flipped. Maritime makes it harder because the people finding the problems are at sea in a time zone that may not overlap with anyone who can help, so support availability has to be defined in the vessel's working hours. Keep the source readable throughout, and run a post-mortem before vessel two — the first vessel exists to improve the second.
Prove It, Do Not Look At It
Counts per object per vessel. Ninety days of due jobs matched line by line. Open defects, deferrals and class conditions matched exactly. Twelve months of expiries matched. Twenty closed jobs read rather than counted. Ten assets found physically and checked against the plate. A rollback threshold agreed before anyone was invested. Two clean dry runs before the first ship. And a fortnight of real support in the hours the vessel actually works. None of that is exotic — it is ordinary migration discipline with a maritime anchor substituted for the financial one, and it is the difference between a migration you signed off and a migration you can defend.
