PMS During a Refit: How to Keep Your Database Current

A refit should improve your vessel. New equipment, upgraded systems, refreshed spaces. And it does — physically. But what happens to the PMS database during a refit is almost always the opposite. The database goes into the yard in some sort of working order and comes out of it broken.

Equipment gets swapped but the old entries stay in the database. New machinery arrives without anyone updating the maintenance schedules. System modifications change how things are configured, but the hierarchy still reflects the old layout. Maintenance history for removed equipment sits alongside active entries, and nobody knows what is current.

We have reviewed databases on vessels fresh out of major refits where the PMS was essentially fiction. Half the equipment listed no longer existed. Equipment that had been installed six months earlier had no maintenance tasks, no spare parts data, and no OEM documentation linked. The crew was running the new systems on experience and memory because the PMS had nothing useful to offer.

This is not an edge case. It is the norm. And the reason is straightforward: refits are chaotic, nobody wants to deal with the PMS during one, and doing it afterwards means working from incomplete information.

This article covers what happens to your PMS during a refit, why it falls apart, and what to do about it.

What a refit does to your database

A refit can affect your PMS database in several ways, and each one creates a different kind of problem.

Equipment replacements

The simplest case. A piece of equipment is removed and replaced with the same type or a direct equivalent. The old watermaker comes out, a new one goes in.

Even this simple case requires more database work than most people expect:

• -The old equipment entry needs to be deactivated or archived, not deleted — you want to preserve the maintenance history
• -A new entry needs to be created for the replacement equipment with the correct manufacturer, model, and serial number
• -All maintenance tasks linked to the old equipment need to be rebuilt for the new equipment, using the new OEM manual — because even a direct replacement from the same manufacturer may have different maintenance intervals in the current manual compared to the one it replaced
• -Spare parts data needs to be updated to reflect the new equipment's part numbers, which may differ even between model years of the same product
• -Running hours counters need to be reset for the new equipment

One piece of equipment replaced, and you are looking at updating the hierarchy entry, rebuilding the task set from the new manual, updating the spare parts catalogue, and resetting counters. Multiply that by every replacement made during a refit.

Equipment upgrades

Harder than replacements. The vessel had a basic watermaker, now it has a larger unit from a different manufacturer with a different configuration. The old HVAC system with two chillers has been replaced with a three-chiller system with new air handling units and a different control philosophy.

Upgrades do not just require new entries — they may require restructuring part of the hierarchy. If the HVAC system went from two chillers to three, the sub-system structure changes. If a new piece of equipment has sub-components that the old one did not (for example, an integrated UV treatment stage on the new watermaker), those need new hierarchy entries too.

The maintenance task sets will be completely different. Different equipment means different OEM manuals with different tasks, different intervals, different spare parts. Nothing from the old entry carries over except perhaps the system-level position in the hierarchy.

System modifications

This is where refits cause the most damage to databases, because the changes are structural rather than item-by-item.

When a refit modifies how systems are configured — new HVAC zones added because the accommodation layout changed, electrical distribution rewired because of new load requirements, hydraulic systems reconfigured to serve new deck equipment — the hierarchy itself needs restructuring.

It is not enough to swap out equipment entries. The parent-child relationships in the hierarchy may need to change. Sub-systems may need to be added, split, merged, or reorganised. The database architecture for those systems needs to reflect the new physical architecture of the vessel.

This is the type of change that nobody thinks about during a refit, because the focus is on the physical work. The database structure is invisible until someone tries to use it and finds that it no longer matches reality.

Additions with no precedent

Refits often add entirely new systems that did not exist on the vessel before. A new tender garage with hydraulic doors. A beach club with its own HVAC and lighting systems. A cinema room with specialised AV equipment. Lithium battery energy storage. Underwater lighting.

These additions need new branches in the hierarchy — new system or sub-system entries, new equipment, new maintenance task sets built from scratch using the OEM documentation. There is no existing database structure to update. It has to be created from nothing.

The documentation gap

Even if you have the time and discipline to update the database during a refit, you face a practical problem: the documentation trail is messy.

Yard work orders

Yards track their work using their own work order systems and their own equipment references. A yard work order might reference "Item 3.4.2 — Replace seawater cooling pump" while your PMS calls the same equipment "Auxiliary Systems > Central Cooling > Seawater Pump No.1." Translating between the yard's documentation and your database structure requires someone who understands both.

This translation problem gets worse when the yard's scope evolves during the refit — as it always does. Equipment that was not in the original scope gets added. Equipment that was supposed to be replaced ends up being overhauled instead. Specifications change mid-project. The final scope of work rarely matches the initial plan.

OEM documentation for new equipment

New equipment arrives with OEM manuals, but the manuals may arrive separately from the equipment, may come in the wrong language, or may not arrive at all until weeks after installation. Getting complete documentation for every piece of new equipment — operation manuals, maintenance schedules, spare parts lists, installation drawings — requires active management.

If you wait until after the refit to gather this documentation, some of it will have disappeared. Packaging gets discarded. Delivery paperwork gets filed in the yard office and never makes it to the vessel. The commissioning engineer leaves and takes their knowledge with them.

Commissioning records

When new systems are commissioned during or after the refit, the commissioning data — baseline readings, initial settings, system parameters — is valuable for future maintenance reference. But commissioning records are often produced for the yard's purposes, not yours. You have to actively request copies and integrate them into your documentation set.

The timing problem

Here is the core issue: nobody wants to update the PMS during a refit.

The Chief Engineer is managing contractors, supervising yard workers, dealing with scope changes, chasing deliveries, testing systems, and handling the hundred daily problems that every refit generates. The engineering team is working extended hours on physical tasks. The management company is focused on budget and timeline. The captain is dealing with the owner and the logistics of getting the vessel back in service.

Updating the PMS database is important, but it is never urgent during a refit. There is always something more pressing. And so it gets pushed to "after the refit."

The problem with "after the refit" is that it means working from memory and incomplete records. Two months after a refit, can you remember every piece of equipment that was replaced, the exact model numbers of the new units, which manuals were delivered and which were not? Can you accurately reconstruct which systems were modified and how?

The answer is usually no. Which is why post-refit database updates are always incomplete, always have gaps, and always result in a PMS that is less reliable than it was before the refit started.

The practical approach

Accepting that refits are chaotic and that nobody has unlimited time for PMS work during one, here is the approach that actually works.

Assign PMS responsibility during refit planning

Before the refit starts, designate a specific person responsible for tracking PMS-relevant changes. This could be the Chief Engineer, a senior engineer with specific database experience, or an external specialist. The point is that someone owns it — it is not assumed that it will happen on its own.

This person does not need to update the database in real time. Their job during the refit is to track changes and collect documentation. The actual database updates can happen during or immediately after the refit, but the information capture must happen during it.

Create a refit change register

Set up a simple tracking document — it can be a spreadsheet — that logs every PMS-relevant change as it happens:

• -Equipment removed (what, where, serial number)
• -Equipment installed (what, where, serial number, manufacturer, model)
• -Systems modified (what changed, how, what the new configuration looks like)
• -Documentation received (which manuals, which spare parts lists)
• -Documentation outstanding (what is still needed)

This register becomes the master reference for all database updates. It captures information while it is fresh, so the database work can be done systematically rather than from memory.

Collect OEM documentation as equipment arrives

Every piece of new equipment that arrives should come with documentation. Operation and maintenance manuals, spare parts lists, installation instructions, commissioning procedures. Collect these as the equipment is delivered, not after it is installed.

Set up a shared folder — digital, not physical — organised by system. As equipment arrives, the documentation goes into the folder. If documentation is missing, it goes on the outstanding list immediately, with the supplier and contact details noted. Chasing a missing manual six months after the refit is ten times harder than chasing it during delivery.

This is the same principle we describe in our guide on preparing documentation for a database build, and it applies just as much to a refit as it does to a new project.

Update system by system as work completes

Rather than waiting until the entire refit is finished to update the database, update it system by system as each scope item is completed.

When the new watermaker is installed and commissioned, that is the time to update the watermaker section of the database. The documentation is fresh. The commissioning engineer is still available to answer questions. The specifics of the installation are clear.

When the HVAC system modification is complete, update the HVAC hierarchy. When the new deck equipment is operational, build the deck equipment entries.

This approach spreads the database work across the refit period instead of concentrating it all at the end. It is more manageable, and each update is done when the information is most complete and most accurate.

Handle maintenance history deliberately

When equipment is replaced, you need a clear policy on what happens to the maintenance history from the old equipment.

Our recommendation:

• -Archive, do not delete. The maintenance history for removed equipment should be archived — moved to an inactive section of the database or exported to a reference file. This preserves the vessel's maintenance record for surveys, insurance, and reference purposes.
• -Do not carry history forward. The new equipment starts with a clean record. Running hours reset to zero. Calendar-based tasks start from the commissioning date. Do not artificially backdate maintenance on new equipment.
• -Document the transition. Note in both the old and new equipment records when the change was made and what was replaced with what. A surveyor reviewing maintenance history two years from now should be able to see clearly that Equipment A was removed on a certain date and replaced by Equipment B.

What happens when nobody updates the database

We should talk about the consequences, because they are not abstract.

A vessel comes out of a major refit. The PMS was not updated. Six months later, the database still shows the old watermaker with its old maintenance schedule. The new watermaker has been running for six months with no recorded maintenance. The HVAC hierarchy still shows two chillers when there are now three. The new hydraulic system for the tender garage has no entries at all.

The Chief Engineer knows what is going on because they were there during the refit. They are running maintenance from their own notes, from OEM manuals stacked in the engine control room, from experience. The PMS is a fiction, but it does not matter because the person who knows the truth is onboard.

Then the Chief Engineer leaves. And the new Chief Engineer arrives to find a PMS that does not match the vessel. Equipment listed that does not exist. Equipment installed that is not listed. Maintenance schedules that reference machinery from before the refit. Spare parts catalogues for equipment that was removed two years ago.

The new engineer cannot trust the database. They have two choices: spend months trying to figure out what is real and what is not, or start from scratch. Either way, the vessel has lost all the value that was in the database before the refit.

This is how refits destroy PMS databases. Not deliberately. Not because anyone made a bad decision. Simply because nobody made database maintenance part of the refit plan.

The difference between a refit that destroys your database and one that improves it

A refit is actually an opportunity. Not just to improve the physical vessel, but to improve the PMS database at the same time. Every piece of new equipment comes with current OEM documentation — often better documentation than the equipment it replaced. Every system modification gives you a chance to restructure and improve that section of the hierarchy. Every replacement is an opportunity to build a better, more detailed task set than the one it replaces.

The vessels that come out of refits with better databases than they went in are the ones that treated database maintenance as part of the refit scope. They budgeted time for it. They assigned responsibility. They collected documentation as it arrived. They updated system by system.

The vessels that come out of refits with broken databases are the ones that treated it as an afterthought.

If you are planning a refit and want to make sure the database comes out the other side intact, think about it early. Include PMS updates in the refit scope. Budget time for it. Assign responsibility for it.

If the database work is more than your team can handle alongside the physical refit, that is where external support makes sense. We work with vessels during and after refits to make sure the PMS reflects what is actually onboard — not what was onboard before the yard period started. You can see how we approach this on our services page, or reach out directly to talk through your refit scope.