Shore-based IT rests on assumptions that do not hold at sea: a fast permanent connection, an engineer who can attend, a stable environment, and equipment nobody inspects.
Remove those four and a great deal has to be designed differently.
Connectivity is the defining constraint
Vessel communications have improved enormously, and they are still not office broadband.
Bandwidth is limited and shared. A whole crew's use, plus operational data, over a link that may be a fraction of a domestic connection.
Latency can be significant. Geostationary satellite links carry a round-trip delay that makes interactive work slow regardless of bandwidth. Low earth orbit services have improved this considerably where coverage exists.
It is not continuous. Coverage gaps, weather, blockage by superstructure during manoeuvres, and antenna problems all interrupt.
It costs real money. An automatic operating system update pulling several gigabytes over a metered link is a genuine expense, and it happens.
Everything else follows from this. Systems aboard must work when the link is down, not merely degrade politely.
Designing for offline
The central discipline of maritime IT.
Data lives aboard and synchronises when it can. Not the reverse. A system that requires a server ashore to function stops when the link does, which is precisely when the crew still has work to do.
Synchronisation must handle conflicts. A record edited both aboard and ashore during a gap needs a rule for resolution, agreed in advance rather than discovered.
Transfers must resume. A file transfer that restarts from the beginning after every interruption never completes over a poor link.
Updates must be controlled. Automatic updating over a metered satellite link is expensive and unpredictable. Updates should be staged — downloaded when in port or on a cheap connection, applied deliberately.
Compress and prioritise. Operational data before crew browsing; text before images.
No engineer aboard
Ashore, someone attends. At sea, the nearest specialist may be days away.
What follows:
Remote support must work over a poor link. Screen sharing that requires a good connection is useless. Command-line access, small file transfers and asynchronous methods are what actually work.
Procedures must be written for a non-specialist. A crew member with other duties needs to be able to restart a service, swap a unit or run a diagnostic from a printed sheet, not from a phone conversation over a poor line.
Spares must be aboard. A switch, a router, cables, and any critical unit. Delivery to a vessel at sea is not an option, and delivery to the next port has its own timetable.
Redundancy matters more than efficiency. Two adequate units aboard beat one excellent one, because the second is available immediately.
Ashore you design for performance and add resilience. At sea you design for resilience and accept the performance that leaves you.
The physical environment
Salt air is corrosive, and it reaches further inside than people expect. Vibration loosens connections and fatigues cables. Temperature and humidity vary widely. Power aboard is less clean than shore supply, and it is interrupted.
Practical consequences: appropriately rated equipment where exposure is possible, connections that are secured rather than simply plugged in, cable runs supported properly, and protection against power disturbance for anything that matters.
Consumer equipment installed aboard fails early, and it usually fails intermittently first.
Separation from regulated systems
This is not a preference. Navigation and safety equipment is subject to survey and type approval, and it must be kept separate from general-purpose computing.
Crew welfare networks, administrative systems and navigation systems should be distinct, with controlled and documented interfaces between them where data genuinely needs to cross.
The reasoning is both regulatory and practical: general-purpose networks carry general-purpose risk, and safety equipment must not inherit it. It is the same principle as network segmentation ashore, applied with considerably less latitude — see VLANs explained.
Any work touching regulated equipment belongs with approved service providers, not with general IT support.
The shore side
Maritime IT is not only aboard. The office running the vessels has its own requirements: keeping in step with vessels that are intermittently reachable, holding certification and survey records, planning maintenance, and reporting to charterers, port authorities and regulators.
Those systems need to tolerate a vessel being out of contact for days and then reconciling a batch of updates, which is a different design from a system where everything is always online.
Security
Maritime cyber security has moved from a niche concern to a survey topic, and vessel networks have real exposures — remote access for equipment suppliers, crew devices, and shore connections. It is covered separately in maritime cyber security.
Why it needs people who know both
Maritime IT sits between two professions. Shore IT specialists design systems that assume connectivity. Marine electronics specialists know the regulated equipment and the environment but are not usually building business systems.
The useful ground is in the middle: understanding what the vessel actually does, what the regulations require, and how to build systems that work with an intermittent link.
Our team's background includes maritime IT and GMDSS-certified radio operation alongside business systems work, which is an unusual combination and a genuinely useful one. Start a conversation if you operate vessels and need systems designed for how they actually work.
