A five-year total cost of ownership model for a marine planned maintenance system turns on one question that has almost nothing to do with the licence fee, and five years happens to be the least decisive horizon on which to ask it. Published analysis of comparable enterprise software is consistent: under year five, subscription is almost always cheaper because of the much lower upfront capital requirement, while beyond year seven perpetual licensing gains a structural advantage, since annual maintenance at eighteen to twenty-two percent of a fully amortised licence sits below recurring subscription rates. Independent studies put cloud's five-year total cost of ownership thirty to fifty percent below comparable on-premise deployments, with on-premise typically not breaking even until somewhere between years nine and eleven. So a five-year model lands squarely in the ambiguous middle, and what decides it is the item nobody puts in the original quote — the major version upgrade, which arrives every three to five years and which the same analysis says changes the comparison materially. In shipping there is a further multiplier that no general TCO guide accounts for: an on-premise deployment is not one server. It is a server on every vessel plus the shore installation, on the same replacement cycle. Start a free trial of Marine Inspection and model your own position honestly rather than against a generic curve.
Years 1-5
Subscription almost always cheaper
Driven by the much lower upfront capital requirement. On-premise front-loads perpetual licences, servers, database licences and implementation, commonly reported to total several hundred thousand to well over a million in year one for comparable enterprise deployments.
Years 5-7
The ambiguous zone, and the one you are modelling
The upfront capital is partly amortised and the annual maintenance fee has not yet fallen below the subscription rate. This is where the answer depends on whether a major version upgrade lands inside the window — and on an upgrade cycle of three to five years, it usually does.
Year 7 onward
Perpetual gains a structural advantage
Annual maintenance at eighteen to twenty-two percent of a fully amortised licence is genuinely lower than recurring subscription. Published analysis puts the on-premise break-even at years nine to eleven, and it only arrives at all under specific conditions listed further down this page.
A five-year model is therefore not a neutral horizon. It is the point at which the two curves are closest together, which means small assumptions — one upgrade project, one hardware refresh, one fleet expansion — swing the answer. Building it honestly means naming those assumptions rather than picking the horizon that flatters the conclusion you already hold.
The Maintenance Fee Is Calculated on List Price
This is the detail that quietly reverses many perpetual licence comparisons, and it is rarely surfaced during negotiation because it does not appear on the year-one invoice. Book a Marine Inspection demo and check the basis on any maintenance clause you are being offered.
The mechanism
Annual maintenance and support is typically eighteen to twenty-two percent of the licence value, every year — and is usually calculated on list price rather than on your negotiated price.
Why that matters more than the percentage
A negotiated discount on the licence reduces the one-time payment and leaves the recurring one untouched. The better your discount, the higher the effective maintenance rate against what you actually paid — so the harder you negotiate, the faster the annual fee catches up with the saving.
Over five years
At eighteen to twenty-two percent annually, five years of maintenance runs to roughly ninety to a hundred and ten percent of the list licence value. On a fully discounted purchase you can pay for the licence again through support before the first upgrade is due.
The question to ask
Is the maintenance percentage calculated on list price or on the price we are paying, is it capped, and what happens to it at renewal. Tier-two vendors are reported around twelve to eighteen percent against twenty-two for the largest, so the range is wide enough to matter.
Two Clocks, and They Converge
The most useful observation about legacy marine PMS deployments is not about cost at all — it is about timing, and it explains why these decisions are so often made under pressure. Sign up for Marine Inspection and find out where you sit on both before either one forces the decision.
Clock one: hardware
Server hardware runs on a refresh cycle commonly cited at five to seven years, and in shipping that is not a single box. It is the shore installation plus whatever sits on each vessel, all ageing at broadly the same rate because they were commissioned together.
Runs from: the date of installation
Clock two: version support
Vendors support versions for a defined period. Once your release passes it, you are running unsupported software or funding a major version upgrade — and perpetual licence holders are responsible for funding those upgrades themselves.
Runs from: the release you are actually on
And they arrive together
Because both were set by the same original deployment date. Industry commentary on legacy marine systems puts it directly: deferral has a shelf life, every year on an older deployment widens the eventual migration, and the two costs that force the issue — hardware end of life and licence renewal — tend to arrive together.
Which means the decision arrives when you have least flexibility
The practical recommendation from the same commentary is worth taking literally: get the vendor's support horizon for your exact version in writing before you plan around it. Not the product's support horizon — the specific release you are running, which on a legacy deployment is frequently several versions behind what the vendor now sells.
Both clocks are already running. Neither of them is on your calendar.
The five-year model you build today is only as good as the two dates you have not looked up — when the hardware reaches end of life, and when your specific version leaves support. Those two dates determine whether year four of your model contains a routine maintenance payment or a capital project, and the difference between those two outcomes is usually larger than every other assumption in the spreadsheet combined.
The Upgrade Is a Project, Not a Download
The single most commonly underestimated line in a five-year model, and the one that decides the ambiguous zone. Schedule a walkthrough and price the upgrade properly before comparing horizons.
What the fee covers
Annual support or maintenance fees may provide access to vendor assistance and to new versions. That is the part people budget for, and it is the smaller part.
What it does not
The internal work required to install, test and release an upgrade. Access to a new version and having it running across a fleet are separated by a project, and the fee covers only the first.
What the project contains
A major version change can become a separate IT initiative in its own right: custom integrations retested, workflows potentially rebuilt, and older modifications that may be incompatible with the new release. On a marine deployment, add rollout across vessels on their own schedules.
How often
Upgrade projects are reported to come around every three to five years. On a five-year model that means at least one falls inside the window, and the published analysis is explicit that the comparison changes materially when a major version upgrade is required.
The Multiplier Nobody Outside Shipping Has
General TCO guidance assumes on-premise means a server room. In a fleet it means considerably more than that, and the difference scales with vessel count rather than with user count. Start a free trial and count what a hardware refresh actually touches in your operation.
Shore
Servers, storage, network components and backup systems that must scale for future growth, plus the facility costs around them — server rooms with cooling, power supply and security. Standard for any on-premise deployment.
Per vessel
Whatever runs aboard so the ship can work without connectivity. Each installation ages on the same cycle, each needs patching, each needs someone competent nearby when it fails, and that someone is at sea.
Replication
The synchronisation between the two, which on a legacy architecture is frequently the most fragile element and the most expensive to modify. It is also where satellite bandwidth cost is created.
The refresh
A hardware refresh in a shore-only deployment is a procurement exercise. Across a fleet it is a project with a vessel schedule attached, phased around dockings and port calls, and the cost scales with how many ships you have rather than with how many people use the system.
One further consideration specific to this category: browser-based versions of established marine PMS products now exist that remove the on-premise server requirement entirely — operators still describing an older on-premise deployment are frequently referring to a release rather than to the current platform. Confirming which you are actually running is the first step in any TCO exercise, because it changes the model before any number is entered.
The Five-Year Model, Line by Line
Build both columns on identical assumptions — same vessel count, same users, same modules, same integrations, same data retention, same support expectations — because a comparison using different assumptions on each side is not a comparison. Book a walkthrough and fill the right-hand column with a real figure rather than an estimate.
Table 1: Five-Year Lines, Both Deployment Models
| Line | On-premise or perpetual | Subscription | Where models go wrong |
|---|---|---|---|
| Software | Perpetual licence, one-time, commonly priced per named user | Recurring fee, typically per vessel or per user | Comparing a one-time figure against an annual one without a horizon |
| Annual maintenance | Eighteen to twenty-two percent of licence value, frequently on list price | Included in the subscription | Omitting years two to five, or applying the percentage to the discounted price |
| Server hardware | Shore plus per-vessel, refreshed every five to seven years | None | Counting one server when a fleet deployment touches every hull |
| Database licences | Separate purchase and separate maintenance | Included | Forgotten entirely, because they were bought years ago |
| Facility | Server room, cooling, power, physical security | None | Treated as existing overhead rather than as attributable cost |
| IT staffing | Dedicated personnel for maintenance, troubleshooting, security, backups and performance | Reduced substantially, though not to zero | Absorbed into existing headcount on paper and not in practice |
| Version upgrade | A funded project every three to five years, with integrations retested | Continuous, included, no project | The single largest omission in most five-year models |
| Disaster recovery | Your responsibility to design, build and test | Vendor responsibility, subject to their terms | Assumed rather than costed, and frequently never tested |
| Security | Patching, monitoring and response, across shore and vessels | Vendor-operated, though the data trust question remains yours | Underpriced relative to what a credible programme actually requires |
| Fleet growth | Marginal cost of hardware and licences per added vessel | Marginal subscription cost per added vessel | Modelling a static fleet, which almost no operator has |
| Satellite bandwidth | Determined by the replication architecture | Determined by the sync architecture | Omitted from both columns, though it belongs in each |
| Exit | You keep running the software if support lapses, on ageing hardware | Service stops; export rights determine what you retain | Not modelled at all, on either side |
12
Twelve lines, and only the first appears on most quotations. Build both columns on identical assumptions or you are comparing two different questions.
When On-Premise Genuinely Wins
This page is published by a cloud platform and would be worth less if it only argued one side. Perpetual licensing has a real structural advantage under specific conditions, and here they are. Start a free trial only if none of these describes your position.
Flat user and vessel counts
Published analysis states on-premise can be cheaper with flat user counts, already-amortised infrastructure, and existing IT staff and database licences. A fleet that is not growing removes the marginal cost advantage subscription models rely on.
Infrastructure already amortised
If the servers, database licences and IT capability already exist and are paid for, the incremental cost of hosting one more application is genuinely low. That is a real advantage and it disappears at the next hardware refresh.
A horizon beyond seven years
Beyond year seven perpetual has a structural advantage because maintenance on a fully amortised licence is lower than recurring subscription. If you genuinely expect to run the same system for a decade without a major version change, the arithmetic favours ownership.
Data sovereignty or offline requirements
Where data residency rules, accreditation requirements or genuine offline operation constraints limit cloud adoption, the decision is not a cost comparison at all. That applies to a narrow set of naval, government and specialised operations, and where it applies it is decisive.
Note what the first three have in common: each is an assumption about the future that you are making today. Flat fleet, no upgrade, no refresh, same IT capability, for seven to eleven years. Published break-even analysis puts on-premise reaching parity somewhere between years nine and eleven, and ten-year comparisons in adjacent categories put on-premise total cost sixty-six to seventy-one percent higher than cloud — so the conditions have to hold for a long time and the penalty for being wrong is substantial.
Questions That Determine Your Own Answer
Nine questions, most of which you can answer this week, and which between them decide the model more than any pricing negotiation will. Schedule a demo and bring the answers rather than the questions.
Table 2: What to Establish Before Modelling
| Question | Why it decides the model | Where the answer is | What a bad answer looks like |
|---|---|---|---|
| What version are we actually on? | Support horizon runs from the release, not the product | The system itself, and the vendor in writing | Assuming you are current when you are several releases behind |
| When does that version leave support? | Determines whether year three or year four contains a project | The vendor, in writing, for your exact release | A general product roadmap rather than a dated commitment |
| When is hardware end of life? | Shore and per-vessel, on a five to seven year cycle | Asset records and installation dates | Not knowing, which means it will arrive as a surprise |
| Is maintenance on list or net price? | Changes the effective annual rate substantially | The maintenance clause in your existing agreement | Never having read the basis, only the percentage |
| What did the last upgrade cost? | The best available predictor of the next one | Project records, including internal time | Only the vendor invoice, which excludes your own effort |
| How many vessels in five years? | Marginal cost per vessel differs sharply between models | Commercial planning, honestly | Modelling today's fleet, which almost nobody keeps static |
| What IT capability do we hold? | On-premise assumes internal capability that must exist and persist | Your own team, and their tenure | Counting a capability that rests on one or two individuals |
| What are our custom modifications? | Older modifications may be incompatible with a new release | Whoever built them, if they still work here | Not having a list, which is common and expensive |
| What does exit look like, either way? | Perpetual keeps running unsupported; subscription stops | Both contracts, read properly | Modelling entry and never modelling exit |
2026 TCO MODELLING REALITY
The cost structures and crossover points cited here come from published analysis of enterprise software generally rather than from maritime-specific TCO studies. Perpetual licence ranges, the eighteen to twenty-two percent maintenance band, hardware refresh cycles, break-even at years nine to eleven and the ten-year cost differential are drawn from ERP, PLM and CMMS analysis published in 2026. They describe the shape of the comparison rather than your figures, and marine PMS products vary considerably in licensing structure. This page is published by a cloud platform. The section on where on-premise genuinely wins is accurate and the conditions in it are real; where data sovereignty, accreditation or offline requirements apply, the decision is not a cost comparison. Established marine PMS products have changed. Browser-based versions now exist that remove the on-premise server requirement, so confirm which release you are actually running before modelling anything — an operator describing an on-premise deployment is frequently describing a version rather than the current product. Nothing here is accounting advice. Capital and operating treatment, depreciation and amortisation should be confirmed with your finance function.
Frequently Asked Questions
Over five years, is subscription or perpetual cheaper?
Under five years, subscription is almost always cheaper because of the much lower upfront capital requirement, and independent studies put cloud's five-year total cost of ownership thirty to fifty percent below comparable on-premise. Beyond year seven, perpetual gains a structural advantage, since annual maintenance at eighteen to twenty-two percent of a fully amortised licence sits below recurring subscription rates, with break-even typically arriving somewhere between years nine and eleven. Five years therefore sits in the narrowest part of the gap, which is why a single assumption — most often whether a major version upgrade falls inside the window — decides the answer.
Why does the maintenance fee basis matter so much?
Because annual maintenance and support is typically eighteen to twenty-two percent of the licence value and is usually calculated on list price rather than on your negotiated price. That means a discount reduces the one-time payment and leaves the recurring one untouched, so the harder you negotiate the licence, the higher the effective maintenance rate against what you actually paid. Across five years at that percentage you pay roughly ninety to a hundred and ten percent of the list licence value in support alone. The range is wide — tier-two vendors are reported around twelve to eighteen percent against twenty-two for the largest — so the basis and the percentage are both worth establishing in writing.
What is usually missing from a five-year model?
The version upgrade, and it is the item most likely to decide the comparison. Annual support fees may provide access to new versions, but they do not necessarily include the internal work required to install, test and release an upgrade — a major version change can become a separate IT project, with custom integrations retested, workflows potentially rebuilt and older modifications possibly incompatible with the new release. Upgrade projects are reported to arrive every three to five years, which means at least one falls inside a five-year window, and published analysis states directly that the comparison changes materially when one is required.
What is different about on-premise in a fleet?
The hardware is not one server room. It is the shore installation plus whatever runs aboard each vessel so the ship can work without connectivity, plus the replication between them — and all of it ages on broadly the same cycle because it was commissioned together. A hardware refresh in a shore-only deployment is a procurement exercise; across a fleet it is a project with a vessel schedule attached, phased around dockings and port calls, scaling with hull count rather than user count. That multiplier does not appear in general TCO guidance because no other industry has it.
Why do these decisions get made under pressure?
Because two clocks converge. Hardware runs on a five to seven year refresh cycle from the installation date, and version support runs from whichever release you are actually on — and both were set by the same original deployment. Industry commentary on legacy marine systems states it plainly: deferral has a shelf life, every year on an older deployment widens the eventual migration, and the two costs that force the issue, hardware end of life and licence renewal, tend to arrive together. The recommended response is equally plain — get the vendor's support horizon for your exact version in writing before planning around it.
When is on-premise the right answer?
Under four conditions, three of which are forecasts. Published analysis states on-premise can be cheaper with flat user counts, already-amortised infrastructure, and existing IT staff and database licences — and beyond year seven the maintenance-versus-subscription arithmetic favours ownership. The fourth is not a cost question at all: where data sovereignty rules, accreditation requirements or genuine offline constraints limit cloud adoption, the decision is made for you. The caution on the first three is that each is an assumption about seven to eleven years ahead, and ten-year comparisons in adjacent software categories put on-premise total cost sixty-six to seventy-one percent higher than cloud when those assumptions do not hold.
Before you build the spreadsheet
Look Up Two Dates
When your hardware reaches end of life, and when your specific software version leaves support. Those two dates decide whether year four of your five-year model holds a routine maintenance payment or a capital project, and that difference outweighs every pricing assumption you are likely to argue about. Then build both columns on identical assumptions — same vessels, same users, same modules, same integrations, same retention, same support expectations — and include the upgrade, the per-vessel hardware, the IT capability and the exit position on both sides. The model is only worth what its least examined assumption is worth.
.png)
