Every future reservation, guest profile, deposit and issued invoice comes across — then gets reconciled against your old system line by line before anyone signs off.
For a full week before cutover, ODA runs in parallel on real data. Your team learns on your own rooms and rates — not on a demo, and not while a guest waits at the counter.
Cutover happens overnight, after the night audit. The desk closes on the old system and opens on ODA the next morning with the same arrivals list.
A typical single-property migration. A larger estate or messier data stretches this; a small guesthouse coming off spreadsheets often finishes sooner.
We sit with your team and map the property as it really works — room types, rate plans, seasons, board arrangements, taxes, services, and who needs which permissions. In parallel we pull the data out of your current system, whatever it is: a native export, a database dump, or a stack of spreadsheets.
We configure the lot — inventory and room attributes, rate plans and restrictions, the tax engine for your jurisdiction, POS menus and price lists, user roles, and your branding on the booking engine and guest app. You review it and we adjust. Nothing is settled on our say-so.
Both systems run at once. Your team takes real bookings through ODA alongside the old system, and each department is trained on the screens it will actually use. We run test arrivals, departures, room moves, folio splits, refunds and a full night audit until nothing surprises anyone.
We repoint your channels, run the final delta migration overnight and go live at your quietest hour. For the fortnight that follows, someone from the implementation team is on call daily — not a ticket queue, the people who built your configuration.
All of it is migrated and then reconciled against your old system before go-live. If a number does not match, we do not cut over.
We will not pretend every migration is clean. Loyalty points and house accounts usually need mapping rather than copying, because two systems rarely count them the same way. Some older systems export only a couple of years of history — we take what exists and archive the rest as read-only files you keep. Free-text notes arrive as plain text, so formatting is lost. All of this is decided in week one, in writing, instead of being discovered in week four.
Scheduled on your quietest night of the week, after the night audit has closed the day. Nobody ever checks in on two systems at once.
The last business day is closed and posted where it has always been, so your accounts have a clean break point.
Everything booked since the week-three snapshot is pulled across, so both systems hold an identical arrivals list for tomorrow.
OTA connections move to ODA. Availability is frozen for the few minutes it takes, so no channel can sell the same room twice.
Arrivals, in-house count, open folios and deposits are compared against the old system. Your duty manager signs off before we stop for the night.
Same arrivals, same balances, new system — with someone from our team online with you through the first shift.
Delivered in your language, on your property's data, in sessions short enough to run between shifts. Every session is recorded, so a new starter in August is not left guessing.
| Who | Time | What they learn |
|---|---|---|
| Front desk | 2 × 90 min | Arrivals, departures, room moves, folios, split billing, payments, refunds and the night audit. |
| Housekeeping | 30 min | The mobile board, room statuses and maintenance tickets with photos — on their own phones. |
| F&B and POS | 60 min | Taking orders, charging to the room, shift close and cash drawer handling. |
| Management | 90 min | Rates and restrictions, occupancy and RevPAR reporting, tax and compliance exports, user permissions. |
Still weighing it up? Talk to sales — tell us which system you run today and we will tell you exactly how that migration has gone before.
Yes, and it happens often. The parallel week exists precisely for this: your team is trained and confident before anything changes, and cutover is scheduled for your quietest night. That said, if your closed season is only a couple of months away, we will usually tell you to wait for it — it is a calmer migration and the price is the same.
That is the normal case, not the exception. Spreadsheets are often easier to migrate than an ageing PMS, because nothing is locked in a proprietary format. Cleaning and de-duplicating is part of week one, and you approve the result before anything is loaded.
Very few can genuinely block you — your reservation and guest data belongs to you, and both most contracts and data-protection rules require it to be handed back in a usable format. Where a vendor drags its feet, we have extracted from database backups, reporting modules and screen exports before. Tell us which system you are on and we will tell you how we have handled it.
No. Issued invoices and credit notes migrate as immutable records, and your existing numbering series is continued rather than restarted, so the sequence an auditor checks stays unbroken. Where a jurisdiction also requires the old system to stay available for a retention period, we say so in the migration plan.
Roughly a day of a manager's time in week one, a couple of hours reviewing the configuration in week two, and the training sessions in week three. We do the extraction, mapping, loading and reconciliation. The one thing we cannot do is decide how your property should be set up — that needs someone who knows the house.
No. We start with one — usually the most complex, because whatever we learn there makes the rest quick — then roll out the others on a schedule you set. Group implementations are quoted per estate.
Your old system stays readable for 90 days and you hold a full export of your data from before cutover. Nobody has needed to reverse a go-live yet, but you are not locked in a room without a door.