BW LNG Picks BASSnet Neo After 30-Vendor Maritime ERP Bake-Off

One in thirty. That is the selection ratio BW LNG ran its maritime ERP procurement against before signing with BASS Software, and it is the number engineering leads at any fleet operator should sit with before approving their next platform RFP. Most enterprise software decisions get made off a three-vendor shortlist and a Gartner quadrant. This one didn't, and the reasons matter for anyone running mission-critical operational technology on legacy on-prem stacks.

The Problem

Maritime ERP is one of the last enterprise software categories where on-premise client-server architecture is still the default. Maintenance scheduling, spares inventory, procurement, and dry-docking workflows on most fleets still run on installations that were architected before mobile apps were a serious delivery channel. The operational cost of that lag compounds: vessels spend weeks at sea with intermittent connectivity, sync windows are brittle, and shore-side analytics teams get data that is days stale by the time it lands in a warehouse.

The BW LNG decision, as The Maritime Executive reported, came after a global review covering up to 30 solutions, with BASSnet Neo selected following technical and operational evaluations that included sandbox testing. That is a meaningful detail. Sandbox testing in maritime procurement is not standard practice; many fleet operators still buy on reference customer calls and a vendor demo. Putting a candidate platform through a working sandbox against real fleet data implies BW LNG's IT organisation has the engineering muscle to actually evaluate architecture, not just feature checklists.

The constraint that has changed is cybersecurity posture. The platform complies with ISO 27001 and the NIST Cybersecurity Framework, and is delivered as a fully managed SaaS. For an LNG carrier and FSRU operator, those are not marketing badges. FSRUs are critical energy infrastructure in several national gas import strategies, and IMO and flag-state cybersecurity expectations have tightened materially over the last three years. A self-hosted ERP that the customer's small IT team has to patch and audit is a liability that gets harder to defend at every insurance renewal.

The source does not disclose the contract value, the migration timeline, or how many vessels are in scope, which matters because the per-vessel licensing economics of cloud-native maritime ERP are the single biggest unknown in this category. We do not know whether BW LNG negotiated a flat-fee SaaS contract or per-hull pricing, but the bound is informative either way: with a fleet that the source describes only as a "leading global" LNG carrier and FSRU operator, the deal is almost certainly seven figures annually, and the renewal mechanics will determine whether other LNG operators follow.

Options on the Table

For a CTO or VP of IT staring at the same decision BW LNG just made, there are realistically four paths, and the trade-offs are not subtle.

Path one: stay on the incumbent on-prem maritime ERP. The case for this is sunk cost and integration depth. Most fleets have ten to fifteen years of customisations, custom reports, and integrations with crewing, voyage management, and accounting systems. Ripping that out is a multi-year program. The case against is that the cybersecurity gap widens every quarter, and the talent pool willing to maintain legacy Delphi or .NET Framework stacks is shrinking.

Path two: lift-and-shift the existing ERP into a hyperscaler VM. This is the path of least resistance and the one I'd argue is the worst value for money. You inherit cloud infrastructure costs without getting any of the cloud-native benefits: no horizontal scaling, no managed patching, no native mobile sync. You're paying AWS or Azure margin to run software that was never designed for that environment. Some operators do this as a stepping stone, but the stepping stone tends to become permanent.

Path three: pick a cloud-native maritime ERP like BASSnet Neo, or competitors in the same category. BW LNG's selection is a data point, not a verdict. The source quotes Per Steinar Upsaker, CEO of BASS Software, calling out "cloud-native architecture" and the platform's ability to "support critical LNG and FSRU operations." Harald Martin Myhre, BW LNG's VP of IT and Digitalisation, specifically cited "modern, future-proof cloud architecture" and the vendor's willingness to work through system validation. That second point is the tell. Validation cooperation is the variable that separates a SaaS vendor that treats your fleet as a tenant from one that treats it as a partner.

Path four: build internally on a generic ERP backbone. A small number of very large operators have done this on SAP S/4HANA or Oracle Fusion with maritime overlays. The cost profile is brutal, the time-to-value is measured in years, and the maintenance burden falls back on the operator. For anyone outside the top ten global fleets by tonnage, this is not a serious option.

The comparison that matters: path three at SaaS pricing versus path one at amortised on-prem cost. The headline number favours on-prem in year one and almost always favours SaaS by year three, once you load in security operations, hardware refresh, and the opportunity cost of stale data. BW LNG clearly ran that calculation.

What Engineering Teams Should Actually Do

The BW LNG playbook is worth copying, with adjustments. First, run an actual sandbox evaluation. Vendor demos are theatre. A two-week sandbox loaded with anonymised fleet data, exercised by your maintenance superintendents and procurement leads, will tell you more than any analyst report. The fact that BW LNG put candidates through this is the single most replicable part of their process.

Second, evaluate cybersecurity compliance as a gating criterion, not a bonus. ISO 27001 and the NIST Cybersecurity Framework are table stakes for any SaaS handling operational data on energy-critical assets. If a vendor cannot show current attestations, drop them from the shortlist. Ask for the SOC 2 Type II report and the penetration test summary. If the vendor is evasive, that is your answer.

Third, scope the integration surface before signing. BASSnet Neo modules going to BW LNG include Maintenance, Materials & Inventory Management, Procurement, and Dry-Docking, plus the BASSnet Inventory, Inspectra, and Projects mobile apps. That is a coherent operational core, but it is not the whole stack. Crewing, voyage management, charter party administration, and financial consolidation will need to integrate. Scope those API contracts in the procurement phase, not after go-live.

Fourth, push for observability commitments. A managed SaaS where the vendor will not give you trace-level visibility into your own tenant's performance is a black box. Standards like OpenTelemetry are now mature enough that asking a vendor for OTLP-compatible export of operational metrics is a reasonable contract clause. The source does not indicate whether BW LNG negotiated this; I'd put it on every term sheet.

If this plays out, we should see at least two more major LNG or FSRU operators announce cloud-native ERP migrations within the next twelve to eighteen months, and we should see at least one incumbent on-prem maritime ERP vendor announce an accelerated cloud-native rewrite or be acquired.

Gotchas and Edge Cases

Connectivity is the first failure mode. LNG carriers on long voyages still have constrained satellite links, and a cloud-native ERP that assumes always-on connectivity will degrade badly during ocean transits. The mobile apps named in the deal, BASSnet Inventory, Inspectra, and Projects, presumably handle offline-first sync, but the source does not confirm this. If you are evaluating any cloud-native maritime platform, the offline behaviour of the mobile clients is the question to stress-test in sandbox.

Second, data residency. FSRUs operate in territorial waters of host nations that may have data localisation rules. A SaaS platform delivered from a single region can create regulatory friction. We do not know which hyperscaler region BASSnet Neo runs in or whether multi-region deployment is offered, and that gap should be closed in any procurement negotiation.

Third, exit costs. Every SaaS contract should specify data egress format, retention after termination, and the timeline for handover. Maritime ERP holds decades of maintenance history that drives warranty claims and class society audits. Losing access to that during a vendor transition is operationally catastrophic.

Fourth, change management on the deck. The best cloud architecture in the world fails if chief engineers and superintendents won't use the mobile apps. Budget for training, and budget more than you think you need.

Key Takeaways

• BW LNG evaluated up to 30 maritime ERP solutions before selecting BASSnet Neo, a selection ratio that should set the bar for serious procurement in this category.
• Sandbox testing with real fleet data is the differentiator between buying on demos and buying on evidence; copy this part of the process.
• ISO 27001 and NIST Cybersecurity Framework compliance are now gating criteria, not nice-to-haves, for any SaaS touching LNG carrier or FSRU operations.
• The contract value, vessel count, and migration timeline are not disclosed, which makes the per-hull SaaS economics the open question that will determine whether competitors follow.
• Watch for two or more peer LNG or FSRU operators to announce similar migrations within twelve to eighteen months; if that does not happen, the cloud-native maritime ERP thesis is weaker than the BW LNG deal suggests.