The Real Cost of System Migration: A Comprehensive Calculator
The booking platform sales pitch usually opens with the headline price. Per booking, per seat, per month — whichever framing the vendor has chosen. Whatever number sits in that pitch is almost always the smallest line item in the operator's actual cost of switching.
The number that matters is everything around it. The export of years of customer history out of the old system in a usable format. The integrations to accounting, payment, OTAs, and email that all need rebuilding. The staff hours retraining a team that knew the old buttons by muscle memory. The parallel-run period when two systems are kept alive at once. The productivity dip during cutover when the office stops selling and starts troubleshooting. The opportunity cost of features in the new platform that take six months to use properly. And the hedge in everyone's head — the bigger the switch, the louder the what if it doesn't work voice.
This article is not a pitch. It is a structured cost model an operator can apply to any platform switch — including a switch to JetSetGo. The framework is the deliverable. The competitive position works only if the framework is honest, so it is.
If the cost model says staying put is the right answer, that is also a valid answer.
Why this calculation matters now
Booking-platform consolidation has been moving faster in the past two years than the previous decade. OTAs have acquired booking systems and started pulling product inventory upstream. SaaS vendors have rolled up smaller competitors. Some operators are watching their current platform get sold to a competitor's parent group. Others are running ageing in-house systems that the original developer no longer maintains. Many are paying for tools built for a different operating model — an activity-booking platform running a vehicle ferry, a tour platform running a multi-modal cruise.
For each of those operators, the migration question becomes live at some point. The cost of the switch is the first question they need to answer before any of the others. And the cost is not what the new vendor quotes.
According to Gartner's research on enterprise application replacement, more than half of software replacement projects exceed their original budget, and roughly a third take longer than planned. The transport and tourism sector is no exception. A 2023 study from MIT's Center for Information Systems Research found that the largest single contributor to cost overruns in mid-sized software replacements was underestimated integration rebuild effort. The headline licence cost is rarely where it goes wrong. Everything else is.
The seven cost columns
A good migration calculator has seven columns. Treat each one as a separate line on the spreadsheet. Sum the lot.
Headline platform cost
Data export and import
Integrations rebuild
Staff retraining
Parallel-run period
Cutover productivity loss
Opportunity cost and risk hedge
Each gets its own column because each is paid for differently. Some are vendor-quoted, some come from the operator's own staff hours, some are a discount on revenue during a specific weeks-long window. Mixing them into a single "total cost of ownership" number hides where the money actually goes.
Column 1 — Headline platform cost
The number on the slide. Per-booking percentage, monthly seat fee, annual contract. Whatever the new vendor quotes. This is usually the only number the new vendor wants to talk about, and it is usually the lowest number on the spreadsheet by a wide margin.
What to write down:
The quoted rate
Setup fees, onboarding fees, training fees, migration assistance fees (separately — some vendors bundle, some itemise)
Minimum monthly or annual commitment, if any
Length of contract and what happens if the operator wants out
What is and is not included in the headline figure (API access, additional users, additional venues, premium support, OTA connectors are common upsells)
Calculate the first-year cost and the steady-state annual cost as two separate numbers. The first year often includes one-off charges that compress over a multi-year horizon.
Column 2 — Data export and import
Years of bookings, customers, products, prices, and operational history sit in the current system. Some of it will come out clean. A lot of it will not.
Three sub-costs:
Export cost from the current vendor. Some vendors offer clean, structured exports. Some offer CSV dumps that lose relational structure. Some charge for "data egress" — a clause buried in the contract that turns the operator's own customer list into a paid export. Some refuse the export entirely until the contract notice period ends.
Cleaning and transformation. Whatever comes out usually needs work. Customer records get duplicated when the same person booked under two email addresses. Product catalogues need re-categorising to fit the new platform's structure. Historical pricing tiers need mapping. Concession types, fare categories, and channel codes need translating between two different conceptual models.
Import and verification. Loading into the new platform, then auditing the result. Spot-checking that totals reconcile, that the customer who booked a season ticket in March still has the right balance, that the corporate-account credit history transferred.
Budget realistically: for an operator with five years of history and a few thousand customers, the cleaning-and-verification stage alone typically runs to one to three weeks of focused work, often spread over a longer calendar period because operations also need running.
Column 3 — Integrations rebuild
This is where most migration projects bleed. The integrations cost is almost always larger than the operator expects, and it is almost always larger than the new vendor estimates.
The integrations to audit:
Accounting — Xero, QuickBooks, MYOB, Sage. The connection itself is usually simple; getting the GL mapping right is the work. Categories, tax codes, agent commission tracking, revenue recognition timing all need to be set up so the accountant does not need to rebuild reconciliation.
Payment processors — Stripe, Adyen, Square, dock-terminal hardware. Card readers may need recertification. PCI compliance scoping changes.
OTAs — Viator, GetYourGuide, Expedia, Klook, Booking.com. Each connector has its own setup. Listings may need rebuilding. Availability synchronisation needs testing.
Email and SMS — Mailchimp, Klaviyo, SMS gateways for booking confirmations and cancellations. Templates need recreating. Sender reputation may need warming up if the sending domain changes.
Hardware — kiosks, ticket printers, QR scanners, dock-side tablets, vehicle weighbridges. Some hardware is portable across systems; some is not.
Custom integrations — anything the operator built or commissioned. Often the most expensive single line item because the original developer may no longer be involved.
Reporting and BI tools — connections to Power BI, Looker, Lightdash, custom dashboards.
For each integration, ask three questions: does the new platform have a native connector, does it have an API the integration can be rebuilt against, or does it require a manual workaround. The answers across the integration matrix drive most of the rebuild cost.
A useful test: list every system the current platform talks to. If there are more than six, the integration rebuild is the single biggest line item on the migration spreadsheet. If there are more than twelve, the project is large and the operator should plan accordingly.
Column 4 — Staff retraining
Booking systems get used hundreds of times a day by people who memorised the button positions and keyboard shortcuts of the old one. A new platform breaks that muscle memory completely. Productivity falls before it rises.
The retraining cost is two things:
Direct training hours. The new vendor provides some, the operator's senior staff provide more. Both cost. Budget at least 4–8 hours per front-line user, more for power users, and accept that the productive learning happens in the weeks after training, not during it.
Productivity drag during the learning curve. A booking that used to take 90 seconds takes four minutes. A weather-cancellation comms broadcast that used to take 15 minutes takes 45. A monthly close that used to take half a day takes two. The drag persists until the team has been through one full operating cycle — usually one peak-and-off-peak rotation, which for many operators means a year.
Two retraining patterns work better than others. The first is a champion model: one or two operations staff get deep training before the cutover, then teach the rest as the transition rolls. The second is a phased rollout by function: switch the office and admin first, then dock-side ticketing, then the public-facing checkout, with each phase being live for a few weeks before the next.
Avoid switching everything on the same day. The productivity loss compounds.
Column 5 — Parallel-run period
For most operators, both systems run at the same time for a window. Bookings on the new platform are tested against the old. Reports are reconciled across both. Hardware setups are duplicated. Staff have to know which system to use when, and the answer changes weekly.
The parallel-run period is paid for in three currencies:
Both platforms billing at the same time. The old contract may still be running. The new platform's fees start at go-live.
Doubled operational load. Every transaction has to be either logged in both or reconciled across both. Mistakes are common; corrections are time-consuming.
Confused customers. A customer who books through the new system, calls about it, and gets handled by a staff member looking at the old system creates a support incident. Expect more of these in the parallel window than in normal operation.
A short parallel-run period (two to four weeks) reduces the financial cost but increases the risk of unmigrated data being lost. A long parallel-run period (two to four months) is safer but expensive. Calibrate to the operator's risk tolerance and the complexity of the historical data.
Column 6 — Cutover productivity loss
The week or two around go-live is the operationally most expensive part of the project. Things that worked yesterday do not work today. Edge cases that were handled by years of operator knowledge in the old system are now bugs in the new one. The team is troubleshooting instead of selling.
Three forms of loss in this window:
Direct revenue loss from bookings that fail to complete because the system is glitching, the staff are unsure, or the customer abandons checkout. Even a small dip — 2-3% of bookings lost — across a peak week can be significant.
Staff overtime to compensate for the slowdown. Cutover weeks are not 40-hour weeks.
Goodwill cost with customers and partners. Travel agents who got used to the old portal need help with the new one. Corporate clients with API integrations need re-authorisation. OTAs need re-syncing.
Time the cutover deliberately. Off-peak is better. School holidays are worse. The week before a major event is the worst possible choice.
Column 7 — Opportunity cost and risk hedge
The hardest column to fill in honestly. Two sub-questions.
Opportunity cost of features not used. A new platform often has capabilities the old one did not — dynamic pricing, channel mix control, multi-modal packaging, hierarchical inventory, audit-grade reporting. The headline saving on the old platform's commission is sometimes the only number the operator looked at, with no model of the revenue uplift those new capabilities might create. The honest move is to estimate both sides.
Use the operator's actual data: how much of last year's revenue came through channels that could have been re-mixed? How many sailings ran below 70% capacity that dynamic pricing might have filled? How many cancelled trips burned through manual refund handling that could have been automated? The uplift estimates should be hedged — features only deliver if the operator actually adopts them. But ignoring them altogether biases the calculation toward staying put.
Risk hedge — the what if it does not work line. Migrations sometimes go badly. The platform might be the wrong fit. The implementation team might over-promise. A critical edge case might not be supported. The realistic move is to add a probabilistic line item: a small percentage of the project budget set aside for the case where the operator has to back out and either return to the old system or move to a third platform. Ten to fifteen percent of the total is a reasonable starting figure; reduce it if the operator has strong references and a contractual exit ramp.
The risk hedge is also where data ownership matters most. A platform that owns the operator's customer data and charges for export raises the cost of backing out. A platform that publishes a clear, supported data-export pathway and a no-contract exit lowers it. Worth asking the new vendor in writing before signing.
Three implementable takeaways
A cost model is only useful if the operator can act on it. Three concrete steps:
1. Build the seven-column spreadsheet before talking to the vendor's salesperson again. Headline cost, data export and import, integrations rebuild, staff retraining, parallel run, cutover loss, opportunity cost and risk hedge. Fill in best estimates for each. The salesperson's job is to tell the operator the first column. The operator's job is to fill in the other six before the conversation continues.
2. Run a thirty-day integration audit. List every system the current platform talks to. For each, check whether the new platform has a native connector, an API that can be used to rebuild the connection, or no path at all. This audit changes the cost of the project more than any other single piece of work. Operators who skip it discover their integration cost six months in.
3. Demand a written data-ownership clause from any new vendor. Specifically: the operator can export their full customer, booking, and product history at any time, in a structured format, at no cost, without contractual notice. The clause is cheap for honest vendors and expensive only for vendors who want to make backing out hard. The presence or absence of the clause tells the operator a lot about the vendor's confidence in their product.
The honest answer about switching to JetSetGo
The framework above applies to a JetSetGo migration as much as to any other. The data export and import effort, the integrations rebuild, the staff retraining, the parallel run, the cutover dip — all of those exist regardless of which platform the operator is moving to. Anyone who claims a switch will be effortless has not run one.
What JetSetGo can speak to honestly: the platform publishes an explicit data-ownership position — the operator owns their data and can export it at any time, with no exit clause to negotiate — which lowers the Column 7 risk hedge. The team that runs the migration has come up through actual ferry and tour operations rather than software-only careers, which helps with the operator-side translation work the new vendor usually does worst. And the multi-modal booking platform is built to handle complexity that single-vertical platforms cannot, which is often the reason the operator is considering switching in the first place.
What JetSetGo will not pretend: the platform is mid-stage. The customer base is being built deliberately. A switch is real work for the operator, real work for JetSetGo's onboarding team, and a partnership that depends on both sides showing up. The seven-column model is the right way to evaluate that partnership, and the right way to evaluate any alternative.
The integrity test for any vendor — including this one — is whether they would still recommend the framework to an operator who decided to switch to one of their competitors. The right answer is yes. A good operator decision is a good operator decision; the platform that loses on the merits should lose.
For operators currently running an activity-booking system that has outgrown them, the true cost of generic booking systems for transport operators covers the symptom side of the same question — what staying put costs, alongside what switching costs. For operators where the trigger is revenue leakage from static pricing or channel blindness rather than platform fit, how transport operators lose revenue without realising it frames the revenue side of the calculation.
The migration question is not "should I switch". The migration question is "what does the full seven-column number look like, on both staying and switching, and which one earns its keep". Operators who answer that question honestly tend to make decisions they do not regret.
Book a demo → to see what the migration model looks like for your specific operation.