How to Migrate Your PMS Database to a New Platform

Switching PMS platforms is one of those projects that sounds straightforward until you actually start doing it. You have data in one system. You need it in another system. Export, import, done. Right?

Not quite.

A PMS migration is one of the most common triggers for vessels to discover just how bad their existing data actually is. The export file comes out, someone opens it, and the problems that were hidden behind the old platform's interface are suddenly visible in raw form. Inconsistent naming. Tasks linked to the wrong equipment. Spare parts floating in a list with no equipment connections. Missing intervals. Duplicate entries.

The migration itself is not the hard part. The hard part is deciding what to do about the data quality you uncover along the way.

Why migrations happen

Before getting into the how, it helps to understand the why — because the reason for migrating affects how you should approach it.

The management company is standardising

This is the most common trigger. A management company decides to move all vessels in their fleet onto a single PMS platform. Each vessel may currently be on a different system, with different data structures, different naming conventions, and different levels of completeness. The migration is as much about standardisation as it is about changing software.

The current platform is not fit for purpose

The vessel has outgrown its current system. Maybe it started on a basic system and the operational demands now require something with better reporting, better mobile access, or better integration with purchasing and inventory systems. The existing platform does the basics, but it is limiting how effectively the crew can manage maintenance.

The vendor is going out of business or ending support

This happens more often than people expect. PMS platforms come and go. A company stops development, merges with another provider, or simply shuts down. If your PMS vendor stops supporting their product, you are eventually forced to migrate — and the longer you wait, the harder it gets.

Better features elsewhere

Sometimes the decision is straightforward. Another platform does things that the current one does not — offline capability, better spare parts management, integrated purchasing, superior reporting. The grass genuinely is greener.

Ownership or management change

A vessel changes hands or changes management companies. The new owner or manager uses a different PMS platform and wants the vessel migrated to match their fleet standard.

In every case, the underlying question is the same: how do you move the data without losing what works and without carrying forward what does not?

The migration process

A proper PMS migration follows a defined sequence. Skipping steps — especially the audit phase — is how migrations go wrong.

Step 1: Export everything from the current system

Start by getting every piece of data out of the existing platform. Equipment records, maintenance tasks with their intervals and history, spare parts with part numbers and linkages, any attached documents or notes.

Most PMS platforms offer some form of data export — CSV files, Excel exports, or platform-specific backup files. The quality and completeness of these exports varies enormously. Some platforms export clean, structured data. Others produce files that need significant cleaning before they are usable.

Export everything, even data you think you might not need. Maintenance history in particular — you do not want to discover six months later that the last five years of maintenance records were left behind because nobody exported the history tables.

What to expect in terms of format:

• -CSV/Excel — the most common and most portable format. Equipment in one file, tasks in another, spare parts in a third, with ID fields linking them together.
• -Platform-specific exports — some systems export in proprietary formats that can only be read by their own import tools. Useful for backups but not for migrating to a different platform.
• -PDF reports — not a data export. If the only way to get data out of your current system is by generating PDF reports, you have a serious portability problem.

If the export is incomplete or the platform does not support proper data export, you may need to extract data manually — which is exactly the kind of vendor lock-in that a portable master file prevents. This is why we always deliver databases as standalone Excel workbooks regardless of which platform the data is imported into.

Step 2: Audit the exported data

This is the step that most people want to skip, and it is the most important one.

Open the export files and actually look at the data. Not a glance — a systematic review. You are looking for:

• -Naming inconsistencies — is the same equipment called different things in different places? "Main Engine Port", "ME1", "M/E No.1 (P)" all appearing in the same dataset.
• -Broken linkages — tasks that are supposed to be linked to specific equipment but are linked to the wrong item, or linked to nothing at all.
• -Duplicate entries — the same piece of equipment entered twice, sometimes with different names, sometimes with slightly different data in each record.
• -Missing intervals — tasks that exist but have no interval set. They were created in the old system but never properly configured, so they never came due.
• -Orphaned spare parts — parts in the catalogue that are not linked to any equipment. They exist in the system but nobody knows what they are for.
• -Outdated equipment — records for equipment that was removed or replaced during a refit but never deleted from the database. Ghost entries that clutter the system.

This audit tells you the real state of your data. And it forces a decision that will determine the success of the entire migration.

Step 3: Decide — clean migration or rebuild

This is the fork in the road, and it is where you need to be honest about what you found in the audit.

If the data is fundamentally sound — the hierarchy is logical, naming is mostly consistent, tasks are linked correctly, and the issues are minor and fixable — then a clean migration makes sense. Fix the problems, map the data to the new platform's structure, and import.

If the data has systemic problems — flat hierarchy, widespread naming inconsistency, tasks linked at system level instead of equipment level, large sections of the vessel barely covered — then importing this data into a new system is not a migration. It is a lift-and-shift of bad data into a new container.

This is what we call the "lift and shift" trap. Moving bad data to a new platform does not make it good data. It makes it bad data on a shinier screen. The problems that existed in the old system — the tasks nobody trusts, the spare parts nobody can find, the equipment that does not match what is actually onboard — will all exist in the new system too.

A migration is often the best opportunity you will get to fix these problems. The data is already out of the old system. It is sitting in spreadsheets where it can be restructured, cleaned, and improved before it goes into the new platform. Taking advantage of this window is the difference between a migration that improves your maintenance capability and one that just changes your login screen.

We wrote about the broader question of [database quality](/blog/what-makes-good-pms-database-superyacht) in a separate article — the standards described there apply just as much to migrated data as to a new build.

Step 4: Map fields to the new platform

Every PMS platform structures its data slightly differently. Equipment records might have different field names, different required fields, different hierarchy depths. Task records might handle intervals differently — some platforms support dual triggers natively, others require workarounds.

Field mapping is the process of aligning your data to the new platform's structure. For each data field in your export, you need to identify where it goes in the new system:

• -Equipment name maps to which field?
• -Equipment hierarchy — how does the new platform handle parent-child relationships?
• -Task intervals — does the new platform use the same format (hours, days, months)?
• -Spare parts linkage — how are parts connected to equipment in the new system?
• -Maintenance history — can historical records be imported, and in what format?

Some mappings are straightforward. Others require transformation — converting date formats, splitting combined fields, merging separate fields, or restructuring data to match a different hierarchy model.

This is technical work that requires familiarity with the target platform's import specifications. Getting the mapping wrong means data ends up in the wrong fields, relationships break, and the imported database does not function correctly.

Step 5: Import and validate

With the data cleaned, restructured, and mapped, it goes into the new platform. Most PMS systems have bulk import tools — upload CSV or Excel files, map them to the platform's fields, and process the import.

Validation happens immediately after import. This is not "does the data appear on screen" — it is a systematic check:

• -Equipment count — does the number of equipment entries in the new system match what was imported? Missing entries mean the import dropped records.
• -Hierarchy integrity — are parent-child relationships intact? Equipment should sit under the correct systems and sub-systems, not floating at the top level.
• -Task-equipment linkage — open a sample of equipment records and verify that the correct tasks are attached with the correct intervals.
• -Spare parts linkage — verify that parts are connected to the right equipment, with correct part numbers and descriptions.
• -Maintenance history — if historical records were imported, verify that they are associated with the correct equipment and show the correct dates.
• -Interval accuracy — spot-check a sample of tasks to confirm intervals imported correctly. A task that should be 500 hours showing as 500 days is the kind of error that an automated import can introduce.

Do not rush this step. A migration that is "finished" but not validated is a migration that will produce surprises — usually at the worst possible time.

Common pitfalls

Losing maintenance history

This is the one that hurts the most after the fact. The old system had five years of maintenance records — every task completed, every date, every running-hour reading. The migration focused on the active data (equipment, current tasks, spare parts) and the history was left behind.

Six months later, a class surveyor asks to see the maintenance history for the main engine turbochargers. The records are in the old system — which has been decommissioned, the license cancelled, and the data inaccessible.

Always export and preserve maintenance history, even if it cannot be imported directly into the new platform. At minimum, keep the export files as an archive. Ideally, import the history so it is accessible alongside current data.

Naming convention conflicts

The old system used one naming convention. The new platform has its own conventions, or the management company has a fleet-wide standard. "Generator No.1" in the old system needs to become "DG1 — Diesel Generator No.1" in the new one.

This is manageable if it is planned. It becomes a problem when it is not planned and the import carries over old names that clash with the new standard. Half the database uses the old convention, half uses the new one, and the crew loses confidence in the data.

Define the naming convention for the new system before you start the import. Transform the data to match during the mapping phase, not after.

Duplicate entries

Duplicates in the old system get imported into the new system and multiply. Or worse — the import process creates new duplicates because of slight differences in how records are matched.

De-duplication should happen during the audit phase. Every equipment entry should be verified as unique before it goes into the new platform.

Missing spare parts data

Spare parts are often the weakest part of any PMS database, and they frequently get lost or degraded during migration. Part numbers get truncated. Equipment linkages break. Quantities reset to zero.

If your spare parts data was poor in the old system, the migration is the time to rebuild it — not to carry the gaps forward. Read our article on [building databases in-house vs professionally](/blog/pms-database-in-house-vs-professional) for perspective on when this kind of rebuild justifies bringing in outside support.

Parallel running

Do not decommission the old system the day the new one goes live. Run both systems in parallel for a defined period — typically 30 to 90 days.

During parallel running:

• -The new system is the primary system for scheduling and completing maintenance.
• -The old system remains accessible as a reference for historical data and as a fallback if problems are found in the migration.
• -The crew reports any discrepancies between what the new system shows and what they expect to see.

At the end of the parallel period, if the crew is satisfied that the new system is complete and accurate, the old system can be archived and decommissioned.

This is not about lacking confidence in the migration. It is about risk management. A vessel cannot afford to discover a critical data gap in the new system with no way to reference the old one.

Crew training

A new platform means a new interface, new workflows, and new habits. Even if the underlying data is identical, the crew needs to learn how to find things, complete tasks, and generate reports in the new system.

Training should happen before the go-live date, not after. Engineers who are confused by the new interface will revert to paper or spreadsheets within days — and once that happens, getting them back into the system is an uphill battle.

Good training covers:

• -Navigation — how to find equipment, open tasks, check what is due.
• -Task completion — how to record completed maintenance, enter running hours, attach notes or photos.
• -Reporting — how to generate the reports the Chief Engineer and management company need.
• -Mobile access — if the platform has a mobile app or tablet interface, the crew needs hands-on time with it. Most maintenance is completed in the engine room, not at a desk.

Keep the training practical. Engineers do not need a tour of every feature in the software. They need to know how to do their daily tasks on day one.

When a migration is really a rebuild

Some migrations are not migrations at all. The data in the old system is so poor that importing it would be a waste of effort. The hierarchy is flat, the naming is inconsistent, half the equipment is missing, and the maintenance tasks are generic templates that do not match what is actually installed.

In these cases, the honest recommendation is to treat the platform change as a trigger for a complete database rebuild. Use the old data as a reference — it tells you what is onboard, even if the structure is poor — but build the new database from scratch using [OEM documentation and a proper methodology](/process).

This costs more than a simple data migration. But it produces a database that is actually worth using, rather than a polished version of the same problems you were trying to leave behind.

The question of when to rebuild versus when to migrate overlaps with the broader decision about [building in-house vs hiring a professional](/blog/pms-database-in-house-vs-professional). If the migration reveals data so poor it needs rebuilding, the time and expertise required usually point toward professional support.

Making the decision

If you are facing a PMS migration — whether by choice or by necessity — here is the honest assessment framework:

1. Export your data and look at it. Not through the platform's interface — in a spreadsheet where you can see the raw state of things. 2. Be honest about what you find. If the data is solid, migrate it. If it is not, do not pretend a new platform will fix it. 3. Define your naming conventions and hierarchy standards before you start — not during and not after. 4. Budget for validation time. The import itself takes hours. Validating it takes days. Do not skip this. 5. Plan for parallel running. Keep the old system accessible. Give the crew time to find and report problems. 6. Train the crew before go-live. Not after.

If you are switching platforms and want to make sure the data that goes into the new system is actually worth having, we can help. Whether that is a clean migration of solid existing data or a full rebuild triggered by the platform change, our [services](/services) cover both scenarios. [Get in touch](/contact) and we can assess what your specific situation needs.