Eight weeks is a realistic timeline for the thing that matters and an unrealistic one for the thing people usually mean. Those are two different milestones and conflating them is how a project that went well ends up feeling like it did not. First vessel productive in eight weeks is achievable and normal on a modern platform. Fleet-wide live in eight weeks is not, unless your fleet is very small or unusually concentrated, because the rollout is paced by drydocking windows and crew rotations rather than by a project plan. And full adoption is later again, because crews rotate several times a year and the people who go live in week eight are not the people who will be using it in month six. The other thing worth saying at the outset is that the eight weeks are mostly not about software. On a platform that is already built, weeks one to three are almost entirely decisions only you can make — what the equipment hierarchy looks like, what goes on the checklists, who gets access, and what overdue means in your company. No vendor can compress that, and no vendor should tell you they can. Start a free trial of Marine Inspection and start making those decisions before the clock starts.

Three Dates People Call Go-Live
Week 8
First vessel productive
One ship running properly — equipment register loaded, checklists configured to how that vessel actually works, crew using the app on deck and in machinery spaces, findings converting into work orders, and a fortnight of real data behind it. This is achievable in eight weeks and it is the milestone worth planning to.
Your calendar
Fleet-wide live
Set by where your vessels are and when, not by the project. Rollouts that work are phased around drydocking windows, port calls and planned crew rotations — the natural points where operations pause or slow. A twelve-vessel fleet trading widely does not reach this in eight weeks and should not try.
Months later
Adoption embedded
When the crew using the system are people who joined after it was installed and were trained into it as normal practice rather than as a change. On a workforce that rotates several times a year, that is two or three rotations past go-live — and it is the point at which the data actually becomes trustworthy.
Announce all three separately. A project that delivers the first vessel in eight weeks and the twelfth in seven months has succeeded, unless somebody told the board it would take eight weeks — in which case it has failed at month three regardless of what it delivered.

Week by Week

This is a real sequence rather than a marketing one, which means the customer tasks are shown alongside the vendor tasks and several weeks are mostly yours. Book a Marine Inspection demo and map this against your own vessel positions before committing to dates.

Week 1
Decide the structure, and start the data audit
Agree the equipment hierarchy that will apply across the fleet, ideally on an industry classification rather than replicating whatever each vessel does now. In parallel, query your existing records rather than reading them — how many vessels, how many assets, how consistent the naming is, how many years of history carry real detail, and how many gigabytes of attachments exist.
Mostly you. The audit result determines whether the rest of this schedule holds.
Week 2
Scope the content and the access model
Which checklists, for which vessel types, with which mandatory items. Who gets access — and on a platform where the value comes from capture at the point of work, the answer should be everybody who does the work rather than a shore team. Decide roles, decide what a defect priority means in your company, and decide what counts as overdue.
Yours entirely. This is the week that separates a system people use from one they work around.
Week 3
Load the fleet register and build the checklists
Vessels, equipment, assets with photographs, serial numbers and classification details. Checklists created, versioned and set up for reuse across vessel types, with mandatory items enforced and photo and note capture built into the items themselves rather than bolted on at the end.
Shared. Vendor does the loading; you supply the decisions and check the result.
Week 4
First vessel configured, crew accounts, app installed
Pick the difficult ship rather than the tidy one. Crew accounts created with the right roles, the mobile app installed from the app stores onto the devices people already carry, and the portal set to whichever of the available languages the crew actually speak — which matters more than it sounds when the deck and engine teams are different nationalities.
Shared, and the first week where anything is visible to a crew.
Week 5
Parallel running on vessel one
The crew do real rounds on the app while continuing whatever they did before. Offline capture with photographs and voice notes, findings raised against equipment, work orders generated from defects. The point is not to prove the software works — it is to find out what your configuration got wrong, which is always something.
Crew-led. Watch what they do rather than asking what they think.
Week 6
Fix what week five exposed
Checklists that were too long, items nobody understood, an equipment hierarchy that did not match the ship, priorities that meant nothing to the second engineer. Revise, re-version and reissue. Every hour spent here saves considerably more across the remaining vessels, because you fix the template rather than eleven copies of the mistake.
Shared, and the most valuable week in the schedule.
Week 7
Vessel one goes live properly, vessels two and three start
The first ship stops running in parallel and the app becomes the record. Vessels two and three begin their own week four and five, using the corrected configuration — which is why they take days rather than weeks. This is where the rollout starts compounding rather than repeating.
Shared, and the shape of every subsequent vessel is now set.
Week 8
First vessel productive, remaining schedule fixed
One ship with a fortnight of genuine data — findings raised, work orders closed, history accumulating — and a dated rollout plan for the rest of the fleet mapped against actual vessel positions rather than against a wish. That plan is the deliverable of week eight, alongside the working vessel.
Yours to own from here, with vendor support rather than vendor leadership.
Weeks one and two contain no software at all
Equipment hierarchy, checklist content, access model, priority definitions, and an honest look at what your existing records contain. Every one of those is a decision only your organisation can make, and every implementation that overruns does so because those decisions were deferred into a week where something else was supposed to happen. Start them before the contract if you can — a free trial costs nothing and answers most of them.
Book Your Fleet Demo Start Free Trial

Who Is Actually on the Critical Path

Implementation timelines usually show only the vendor's tasks, which makes the customer's contribution invisible until it becomes the delay. Both columns below are real work. Sign up for Marine Inspection and name an owner for the left-hand column before week one.

Yours
Deciding the equipment hierarchy and whether it standardises across vessels
Auditing existing records honestly before anything is loaded
Writing or approving checklist content per vessel type
Defining priorities, overdue thresholds and what closure requires
Deciding who gets access, which should be everyone who does the work
Choosing the pilot vessel and getting its master and chief engineer engaged
Mapping the rollout against real vessel positions and rotations
Naming the person who owns this and what they stop doing
Theirs
Loading the fleet register, equipment and assets from your data
Building the checklist templates to your specification and versioning them
Configuring roles, access and the portal language per user group
Setting up preventive schedules, intervals and counter triggers
Delivering training to the pilot crew and to shore staff
Supporting the parallel-running week and diagnosing what breaks
Reissuing the corrected configuration to subsequent vessels
Being available at whatever hour the pilot vessel actually needs them
Notice the balance. The vendor's column is execution against decisions; yours is the decisions themselves. That is why a compressed timeline almost never fails on the vendor side — it fails because a checklist question sat unanswered for nine days while the person who could answer it was dealing with a vessel.

When Eight Weeks Holds, and When It Does Not

Being specific about the conditions is more useful than either promising or hedging. Schedule a walkthrough and establish honestly which column your operation sits in.

Eight weeks is realistic when
The target is first vessel productive rather than fleet-wide live
One named person owns the project and has actual time for it
The equipment data exists in some structured form, even imperfectly
Decisions about hierarchy and checklists can be made in days, not committees
The pilot vessel's master and chief engineer are willing rather than instructed
The platform deploys in weeks by design rather than being configured from scratch
Eight weeks will not hold when
The scope is the whole fleet, which is paced by dockings and rotations
A material share of existing records turn out to be incomplete or inconsistent
Legacy history has to be migrated and validated rather than started fresh
Integrations to finance, crewing or procurement are in the first phase
Nobody internal owns it, so decisions queue behind operational work
The platform requires months of configuration before it does anything
On the second point in the right-hand column: one documented 2026 fleet migration spent three months auditing a legacy database before touching production and found roughly thirty percent of crew certificate records incomplete or in inconsistent formats. That was discovered because somebody looked. If nobody looks in week one, the same discovery happens in week five and the schedule is gone. The audit is not a delay to the timeline — it is what makes the timeline knowable.

The Training Decision Nobody Gets Right

Where you place go-live relative to the crew rotation determines how much of your training investment survives, and the obvious answer is the wrong one. Start a free trial and think about who is aboard in week five rather than in week one.

The obvious answer
Go live at a crew change, because it feels like a clean boundary — new system, new crew, fresh start. It is a clean boundary for the record and a poor one for the training, because you have just taught the outgoing crew and handed the vessel to people who have never seen it.
The better answer
Train mid-rotation and go live with a settled crew who have several weeks left aboard. They learn it, they use it under normal conditions, they find the problems while there is still time to fix them, and they hand over to the next crew with the system already working rather than as an unfamiliar addition.
And plan for the handover
The incoming crew is trained by the outgoing one plus whatever self-service material exists, which makes the quality of that material a real project deliverable rather than an afterthought. A newly joined engineer at two in the morning needs to be able to work it out alone, and that is a design requirement rather than a training one.

What the First Vessel Should Be Doing by Week Eight

Define this before week one, because a go-live with no success criteria cannot be assessed and will be argued about instead. Book a walkthrough and agree the measures in advance.

Table 1: Success Criteria for the Pilot Vessel
Measure What good looks like How to check it What a bad result means
Capture time A finding with a photograph recorded in seconds, standing at the item Time it with a crew member on deck, not at a desk The configuration is too heavy, not that the crew are resistant
Who is recording Entries from across the department, not only from one officer Count distinct users making entries in the last fortnight Access was scoped too narrowly, or the app is too slow to bother with
Offline behaviour A full round completed with no connectivity, syncing cleanly afterwards Airplane mode, real round, photographs and voice notes included An architecture problem, and a serious one at sea
Findings to work orders Defects raised during inspections converting into tracked tasks Count conversions, and check they carry an owner and a date The workflow is not configured, or people do not trust it yet
Closure evidence Completed jobs carrying measured values and attribution, not ticks Open five closed jobs at random and read them The record will not survive an audit, which is the whole point
History retrieval Previous work on a unit findable at the machine within seconds Ask a second engineer to look something up while standing next to it The hierarchy is wrong, or history was not loaded deep enough
Checklist fit Items that make sense on this vessel, in the crew's language Ask the crew which items they skip and why Template imported rather than configured, and it will spread
Shore visibility The superintendent can see open items on that vessel without asking Have them try it, cold, without help Reporting is configured for a demo rather than for a Monday morning
Crew verdict Faster than what it replaced, said by someone with no stake Ask the second engineer, not the chief engineer The single most reliable predictor of whether this survives year one
Week 5
The parallel-running week is the one that determines everything after it. Its purpose is not to demonstrate that the software works — it is to find out what your configuration got wrong while the mistake exists on one vessel instead of twelve.
Book a Demo Start Free Trial

After Week Eight

The schedule does not end at go-live, and the work that follows is different in kind rather than a continuation. Start a free trial and plan the second phase before the first one finishes.

Vessels two onward
Each subsequent vessel takes days rather than weeks, because the configuration is settled and only the equipment register and crew accounts are ship-specific. The constraint becomes vessel availability, so the schedule is a list of dockings and port calls rather than a sequence of project weeks.
Rotation retraining
Begins immediately and never stops. Every crew change brings people who have not used the system, which makes self-service material and interface obviousness recurring operational concerns rather than implementation line items.
The second module
Whatever you deliberately left out of phase one — procurement, fuel, crew certification, logbooks. Adding it to a platform people already use is a fraction of the effort of including it in an initial rollout, which is the main argument for leaving it out.
The integration phase
Connections to finance, crewing or procurement systems belong here rather than in week three. Integration work is consistently underestimated at twenty to forty percent of implementation effort, and putting it in phase one is the most reliable way to turn an eight-week schedule into a six-month one.

What Slips, and Why

Nine recurring causes, only one of which is the software. Schedule a demo and check the plan against each before committing to a date.

Table 2: Causes of Slippage, and the Prevention
Cause How it presents When it bites The prevention
No named owner Decisions queue behind operational work and nobody escalates Weeks two and three, invisibly One person, a stated time commitment, and what they stop doing
Data worse than assumed Loading exposes inconsistent naming and missing fields Week three, when it should have surfaced in week one Audit by querying the data, not by looking at a screen
Scope creep into modules Procurement and crewing added because they are also needed From week two onward, compounding Phase one is inspection and maintenance; everything else is phase two
Integrations in phase one Connector work absorbing the weeks meant for configuration Weeks three to six Defer all integrations until the core is live and used
Wrong pilot vessel The tidiest ship chosen, so nothing difficult is discovered Week nine onward, on the other vessels Pilot the awkward one deliberately
Checklists too long Crews skip items or complete rounds at a desk afterwards Week five, if anybody is watching Watch a real round; cut anything that does not change a decision
Access scoped narrowly Only officers have accounts, so capture never reaches the work Immediately, and it looks like low adoption Give access to everyone who does the work, from week four
Training at a crew change The trained crew leaves and the new one arrives cold Two weeks after go-live Train mid-rotation with a settled crew
One date announced Fleet-wide expectations set against a first-vessel timeline Month three, as a perceived failure Announce the three milestones separately, from the start
2026 IMPLEMENTATION REALITY
Eight weeks describes first vessel productive on a platform designed for rapid deployment, not fleet-wide completion. Published comparisons put modern subscription platforms live in a matter of weeks, mid-market modular products at three to six months, and enterprise suites at six to fifteen — so the achievable timeline is substantially a function of which category of product you have selected, and that decision precedes any project plan. Fleet rollout is paced by your vessels, not by the project. Successful maritime migrations phase around drydocking windows and planned crew rotations rather than an IT release schedule, which means the completion date is determined by a calendar you do not control. Data condition is the largest single variable. One documented fleet migration found roughly thirty percent of certificate records incomplete or inconsistent after a three-month audit; your own position may be considerably better or worse, and the only way to know is to look before committing to dates. This page is published by a software vendor, and the honest caveats above apply to our own implementations as much as to anybody else's.

Frequently Asked Questions

Is eight weeks realistic?
For first vessel productive, yes, on a platform built for rapid deployment. For fleet-wide live, no — that is paced by drydocking windows, port calls and crew rotations rather than by a project plan, and a widely trading fleet takes months regardless of how good the software is. For full adoption, later again, because crews rotate several times a year and the people live in week eight are not the people using it in month six. Announce those three separately. A project delivering the first vessel in eight weeks and the twelfth in seven months has succeeded, unless somebody promised the board eight weeks for everything.
What actually happens in the first two weeks?
Almost no software. Week one is agreeing the equipment hierarchy that will apply across the fleet and auditing your existing records by querying them rather than looking at them — how consistent the naming is, how many years of history carry real detail, how many attachments exist. Week two is checklist content per vessel type, the access model, role definitions, what a defect priority means in your company and what counts as overdue. Every one of those is a decision only your organisation can make, and deferred decisions are the most common cause of overrun in implementations of this kind.
Which vessel should we pilot on?
The difficult one. A pilot on your best-maintained ship with your strongest crew proves nothing anybody will believe and, worse, surfaces none of the problems you need to find while they are cheap to fix. Choose a vessel with awkward equipment, mixed record quality and a crew who will say plainly when something is slow. The purpose of the parallel-running week is not to demonstrate that the software works — it is to discover what your configuration got wrong while the mistake exists on one vessel rather than on twelve, and a tidy pilot cannot do that.
Should we go live at a crew change?
Generally not, despite it feeling like the obvious clean boundary. Going live at a rotation means you have just trained the outgoing crew and handed the vessel to people who have never seen the system. Better to train mid-rotation and go live with a settled crew who have several weeks left aboard — they learn it, use it under normal conditions, find the problems while there is time to fix them, and hand over with the system already working. That makes the quality of self-service material a real deliverable, since the incoming crew is trained partly by the outgoing one and partly by whatever exists in the app.
What should we deliberately leave out of phase one?
Integrations, and any module that is not inspection and maintenance. Integration work is consistently underestimated at twenty to forty percent of implementation effort, and placing it in the first phase is the most reliable way to convert an eight-week schedule into a six-month one. Procurement, fuel, crew certification and logbooks are all easier to add to a platform people already use than to include in an initial rollout, because by then the configuration is settled and the crew are not learning two things at once. Deferring is not a compromise here; it is the design.
How do we know week eight actually succeeded?
By measures agreed before week one, because a go-live with no success criteria gets argued about instead of assessed. Useful ones: how long a finding with a photograph takes to record standing at the item, how many distinct people made entries in the last fortnight, whether a full round completes offline and syncs cleanly, whether findings are converting into tracked work orders with owners and dates, whether closed jobs carry measured values rather than ticks, and whether a second engineer can retrieve previous work on a unit while standing next to it. The most predictive of all is simply whether the crew say it is faster than what it replaced.
The eight weeks are mostly yours
Start the Decisions Before the Clock Does
Equipment hierarchy, checklist content, access model, priority definitions and an honest audit of what your records actually contain — five decisions that occupy weeks one and two and that no vendor can make for you. A free trial answers most of them at no cost and before any commitment: load a handful of assets, build a checklist the way you would actually want it, put it on a phone and have somebody walk a real round with it. Do that first and the eight weeks start from a much better place than a contract signature.
Schedule Your Demo Start Free Trial Today