Moving to new PMS software is one of the riskiest data projects a ship manager runs. Every system has its own structure, codes and import format, and the old database usually carries years of inconsistencies. Done badly, a migration loses maintenance history, resets counters, breaks the link between parts and jobs, and leaves crews with a new system they do not trust.
What a migration covers
- Extraction. Equipment, jobs, intervals, counters, spare parts, stock and maintenance history from the existing system or its exports.
- Cleansing. Duplicates, obsolete equipment, generic job wording and unexplained intervals found and corrected before the move.
- Mapping. The old hierarchy and codes mapped to the new system's structure, for example SFI or your company standard, with a mapping table you can review.
- History and counters. Last-done dates, running hours and outstanding jobs carried across, so nothing restarts from zero.
- Spares and links. Parts kept linked to their equipment and jobs.
- Validation. Record counts and spot checks per vessel, comparing the new data with the old, before go-live.
How we run it
- Assess the source data, usually with a PMS health check.
- Agree the target structure and mapping rules with your team and, where needed, the software provider.
- Pilot one vessel, review it with your superintendents, and adjust the rules.
- Roll out across the fleet in batches, validating each vessel.
- Cut over on board with the history in place, and keep an archive of anything that could not be mapped.
Structuring data for the long term
A migration is also the best moment to fix structure: one equipment hierarchy across the fleet, consistent job wording, standard failure and criticality codes. Our white papers on PMS data migration and equipment hierarchy and master data describe the approach in depth.
We work with the import formats of the leading PMS platforms. See PMS software we work with.