Hotel Management Software Migration Checklist: 10 Steps to Lose No Data

17/08/2026

For a 4–5 star hotel, a resort or a chain that has run on an on-premise system for years, the hardest question when considering a change of software is rarely "is the new product better". The hard question is: what happens to the twenty years of data sitting inside it — guest profiles, stay history, tour operator receivables, deposits from groups already booked for next year's peak season. That concern is entirely legitimate, and it is exactly why many leadership teams keep deferring a decision they should have made long ago.

This article is not about features. It is an operational checklist for the people accountable: the general manager, the chief accountant, the front office manager and the IT team. Earlier articles in this series covered vendor due diligence criteria and how to read a P&L to international standards; this one does exactly one thing — how to migrate without losing data and without interrupting the business.

Part 1: Does changing hotel management software mean losing data?

The straight answer: no, provided the migration follows a controlled process. Data is only lost in three situations, and all three are preventable:

Scope was never agreed before the move. The two sides understood "data migration" differently. Discovering on go-live day that prior-year stay history was out of scope is far too late.
No reconciliation by the numbers. The move finishes, the screen shows data, and it is treated as done. The discrepancies sit in period revenue totals, in receivable balances, in record counts — things that only surface when two tables are placed side by side and compared line by line.
No way back. The old system is switched off on migration night, with no full backup and no rollback plan. A small incident then becomes a large one, because there is nowhere left to return to.

In one properly prepared migration, our team moved more than 60,000 guest profiles and more than 5,000 bookings: the run took under 15 minutes, reconciliation matched 100%, and the whole process was reversible — had reconciliation failed, the system would have returned to its pre-migration state. Those figures come from one specific project, not a promise applied to every hotel; the point to take away is not the elapsed time but that migration is something you can measure and reverse.

🧭 Three commitments we write into the migration contract: go-live in one day — the hotel does not close and does not stop taking guests; parallel running — the old system stays open in read mode for comparison; rollback available — every step can return to its prior state. These matter more than any promise about speed, because they turn risk into something manageable.

Part 2: Signs the software you run has stopped evolving

Not every legacy system needs replacing. Plenty of on-premise software has run stably for a decade and still serves well. The problem only appears when the software stops being developed — at that point it does not get worse, but the world around it changes. Below is an objective set of criteria for examining your own system; it is not intended to judge any particular vendor.

Four verifiable criteria

No new release for a long time. Open the system's version log: when was the most recent update issued, and what did it contain? A living product leaves a regular trail. If the version you run has stood still for years, that is a fact, not a feeling.
Not keeping up with new regulation. This is the easiest criterion to verify because the law has firm dates: the corporate accounting regime under Circular 99/2025/TT-BTC, e-invoicing connected to the tax authority, automated residence declaration for domestic and foreign guests. How many of those does your system support, and how many hours a month is your team doing the rest by hand?
Slow support, or no response at all. Take real figures from the operations team: for the last three support requests, how long until someone replied, how long until it was resolved, and which contact points are still active? The feeling of "we call and nobody answers" should be converted into a number of days before it goes into a meeting.
No published product roadmap. Ask the vendor directly: what will the product gain over the next twelve months, when will it meet the regulation coming into force, and who is accountable? A product being invested in can always answer that in writing. No answer is also an answer.

Why this matters for 4–5 star hotels and chains

Compliance risk lands on the hotel, not on the software. When a regulation changes and the system does not, it is the hotel management team that explains itself to regulators and auditors.
Manual effort is a real cost. A few dozen hours a month of manual entry, manual reconciliation and manual reporting adds up over a year to far more than the licence-fee difference between two options.
The longer you wait, the harder it gets. Data accumulates daily, the people who know the old system leave one by one, technical documentation erodes. The easiest time to migrate is always today compared with next year.

If your system meets two or more of those criteria, the sensible move is to a platform that is continuously developed — with an engineering team behind it, a release schedule, and a written commitment to regulatory updates. That is what AI hotel management software DiHotel has sustained for more than twenty years across over 300 properties in Vietnam and Japan.

🎁 Migration offer for hotels running legacy systems: all data migration work free of charge — guest profiles, stay history, room and rate catalogues, receivable balances; additional months of use matching the time remaining on your old contract, so you are not paying twice during the transition; and a trial on your own hotel's real data before you sign — we move a copy of your data into a test environment so you can verify it yourself instead of watching a prepared demonstration.

Part 3: The 10-step safe migration checklist

This is the core of the article. The ten steps below are the process we apply to migration projects in the 4–5 star and chain segment; you can use it verbatim as an acceptance checklist with any vendor.

Step 1 — Sign off the data scope in writing

List exactly which data groups move: guest profiles, stay history, room and room-type catalogues, rate plans and negotiated rate contracts, tour operator and channel partner lists, receivable balances, future bookings, folios of in-house guests, and the goods and services catalogue.
State clearly which groups do not move and why — usually detailed vouchers from many years back, audit trails, and configuration data specific to the old system.
The scope must be signed by the chief accountant and the front office manager, not only by IT.

Step 2 — Take a full backup of the old system and store it separately

Create a complete backup before touching anything, stored apart from the running system.
Verify the backup by performing a test restore — a backup that has never been restored successfully is not yet a backup.
Record it formally: who created it, when, its size, where it is kept, and who holds access.

Step 3 — Clean the data before moving it

Merge duplicate guest profiles, standardise tour operator names, remove catalogue entries unused for years.
An unbreakable rule: clean in the old system or in a staging table, never by hand after the move into the new system — later edits destroy every reconciliation check.
This is also the rare opportunity to tidy up catalogues everyone knows are messy but nobody has had a reason to fix.

Step 4 — Trial migration into a test environment

Move the full dataset into a separate environment, fully isolated from the system that will go live.
Run a complete operational cycle on it: check-in, posting services, mid-stay room moves, splitting and merging folios, check-out, night close, report generation.
An error found here is many times cheaper than one found after go-live — so this step is never abbreviated, however tight the schedule.

Step 5 — Reconcile by the numbers, not by impression

Build a reconciliation sheet across three groups: record counts (guest profiles, bookings, invoices), period totals (room revenue and service revenue by month), and balances (receivables by partner, deposits).
Write the acceptance criterion into the minutes: zero variance, or every variance explained and signed off.
The people reconciling must be the hotel's own — accounting and front office — not the vendor self-certifying and reporting success.

Step 6 — Train before go-live day, not on it

Train by real shift and real role: front office, housekeeping, restaurant and point of sale, accounting, management.
Let staff work on their own hotel's data in the test environment — familiar room numbers, familiar rate names, familiar partner names.
Nominate a local super-user in each department to help colleagues through the first week, reducing dependence on the support line.

Step 7 — Pick the right cutover moment

Prefer a low-occupancy weekday; avoid peak season and days with large group arrivals or banqueting events.
Set the cutover immediately after an accounting period close — the opening balances are then settled figures, not moving ones.
Agree "T-hour" to the minute and announce it in advance to every department, including reservations and sales.

Step 8 — Move the production dataset and open the new system

Re-run exactly the script rehearsed in step 4, this time on the dataset frozen at T-hour.
The old system switches to read-only immediately — still searchable, but nobody can post to it, which prevents data splitting into two streams.
The operational target: go-live in one day, with the hotel taking guests as normal throughout.

Step 9 — Parallel running with on-site supervision

During parallel running the old system stays open for reading so anything can be checked against it; new transactions are posted only to the new system.
Place support staff at the desk in person for the first shifts, especially the night shift running the first night audit.
Reconcile the first day's revenue that same night, never leaving it until the next day.

Step 10 — Acceptance, handover and the archiving plan for the old system

Sign the acceptance minutes with the matched reconciliation sheet attached, plus the open-items list and an owner for each item.
Keep the old system read-only for a further 3–6 months for historical lookups, then archive it under your internal record retention policy.
Hand over the documentation: the data mapping diagram, reconciliation minutes, accounts and permissions, and support contacts.

✅ If you remember only three of the ten steps: back up and test-restore before touching anything (step 2); reconcile by the numbers, signed off by the hotel's own people (step 5); and always keep a way back — the old system read-only plus a rollback plan (steps 8 and 10). Those three are the difference between a migration and an incident.

Part 4: Migrating receivables, opening balances and in-house guest records

This is where many migrations stumble, because two kinds of data look alike but must be handled in completely opposite ways. The principle we use is "close the old ledger, open the new one".

Historical partner receivables: do NOT migrate the detail

Move only the opening balance into the new system: one single line per partner, without carrying across every invoice and every payment from years past.
Each balance line comes with a detailed schedule attached — still fully searchable when needed, but held as a document rather than as thousands of transaction records in the new system.
You need a receivables confirmation signed by both parties between the hotel and each tour operator and channel partner. That is the legal basis for the opening figure; without it, later disputes have nothing to stand on.
Keep the old system read-only for 3–6 months so transaction history can be retrieved for claims or reconciliation.
Why not migrate the detail: years of receivables data almost always carry accumulated discrepancies. Moving it as-is means importing every old discrepancy into the new system and mixing it with new data, after which nobody can tell where an error came from.

In-house guest folios: MUST be migrated booking by booking

Guests physically in the hotel at cutover must arrive in the new system with each booking intact: correct room, correct rate, correct arrival and expected departure dates, correct guest count.
Everything already posted to the folio — room charges for nights already stayed, restaurant, spa, laundry, charges routed to the room — must carry across line by line, never collapsed into a single total.
The reason is entirely practical: the guest will check out in the new system and ask for an itemised invoice. A single lumped line cannot be explained to the guest, cannot be split to the correct department, and misstates the reports of both periods.
Before T-hour, print the folio listing for all in-house guests from the old system; after the move, check every room and every amount. The number of occupied rooms is usually modest, so manual verification is entirely feasible and very much worth doing.

This separation keeps the new hotel management system clean from day one: the new ledger holds only what is still live — in-house guests, future bookings, settled balances — while the past sits neatly in the archive, retrievable but not polluting operational figures.

Part 5: Handling future booking deposits during a system change

Deposits are the item most easily lost in a migration, because they are money collected for a service not yet delivered — sitting on the boundary between cash flow and revenue. For resorts and conference hotels taking bookings a year ahead, the amounts are far from trivial.

The handling principles

Main rule — if a deposit can be traced to a booking, attach it directly to that booking. Every deposit carries the booking reference, guest or group name, expected arrival date, amount, date received and payment method. Lumping them into a single "deposits payable" total is the surest way to ensure nobody can find a guest's money on the day they arrive.
Group and banqueting contract deposits need an extra layer. Many contracts have staged deposits, date-change clauses and cancellation penalties. The migration must preserve the payment schedule, not just the amount already received.
Reconcile three ways before T-hour. The deposit list in the old system — bank statements and the cash book — and the future booking list. All three must agree; wherever they differ, resolve it before the move rather than carrying it into the new system to sort out later.
Deposits collected through online channels need the channel and reconciliation status recorded, because the recognition date often differs from the date the money actually lands.
Brief the sales and reservations teams. During migration week, every newly collected deposit is posted to one system only, according to the agreed T-hour. This is a human convention rather than a software matter, and it is where mistakes most often occur.

Edge case: deposits that cannot yet be matched to a booking

Any long-running system leaves a group of suspense items: holding money from guests who have not fixed their dates, deposits collected through one contact and not yet split by guest, amounts sitting in a collection account or a "dummy room" used to hold funds. These cannot be attached to a specific booking, and the handling rule is:

Never force them onto an arbitrary booking just to give them somewhere to sit. That creates a fictitious deposit on an unrelated booking, produces the wrong amount at check-out, and cannot be traced back to its origin.
Convert them into an opening balance in the accounting module, as a credit balance — they are guest money held by the hotel, that is, a liability rather than revenue.
One line per item, never merged into a single total, with a detailed schedule attached: date received, amount, payer or contact, and a note on the circumstances. With that schedule, when the guest fixes their dates or the partner comes to reconcile, accounting can trace it immediately.
Once a suspense item is identified, handle it normally in the new system: offset it against the relevant booking or refund it, and reduce the opening balance accordingly. By the end of the first quarter the remaining suspense figure should be close to zero — if it is still large, that signals the deposit intake process needs tightening, not that the migration failed.

For multi-property chains this multiplies by property count and needs a single owner tracking progress — which hotel chain management software DiHotel handles by consolidating the deposit and future booking lists for the whole portfolio in one place, split by property but still viewable as a whole.

Part 6: On-premise versus cloud — compare before deciding

A migration is a rare chance to revisit the architecture, not merely to change the name of the software. The table below compares the two models on the criteria that genuinely affect operations at 4–5 star hotels, resorts and chains.

Criterion	On-premise	Cloud	What it means for the hotel
Upfront cost	Servers, licences and a server room	Periodic fee, no hardware investment	Capital freed for other uses
Version updates	In waves, requiring scheduled downtime	Continuous, applied centrally	Keeps pace with new regulation
Backup & restore	Organised and verified by the hotel	Automatic, multiple point-in-time copies	Lower risk of data loss
Multi-property management	One system per property, consolidated by hand	Portfolio consolidation built in	Chain reporting within the day
Remote access	Requires dedicated connectivity setup	Open a browser or the app	Owners see the numbers any time
Connectivity dependence	Runs on the local network	Needs stable internet, ideally with a backup line	Assess by location
On-site device integration	Direct connection on the local network	Through a middleware component on site	Survey before committing
System operations staff	Someone must tend the server on site	Handled by the vendor	Lower recurring cost

No model is right for every case. A resort where connectivity is still unreliable, or a hotel with specific requirements to keep data on site, has legitimate reasons to stay on-premise — provided the software running there is still being developed. For smaller properties in the same portfolio, cloud AI hotel management software DiCloud is usually the more sensible choice on cost, while larger properties, resorts and conference hotels use resort management software DiHotel for the complex operations. Both platforms sit in one ecosystem, so reporting consolidates rather than being merged by hand.

Part 7: Parallel running, reconciliation and the rollback plan

These three are the shock absorbers of the whole project. Dropping any of them adds more risk than the time it saves.

Parallel running done properly

Never double-key into both systems. Staff entering everything twice will tire, will make mistakes, and the two systems will end up disagreeing — precisely what we are trying to avoid. Parallel running means the old system is open for reading; new transactions are posted only to the new system.
Sensible duration: the first few weeks are the close-supervision phase, after which the old system stays read-only for 3–6 months for lookups.
One decision owner. Situations without precedent always arise in this phase; you need one person with authority to settle them immediately, rather than each shift improvising differently.

Which numbers to reconcile

Revenue by day and by department — rooms, food and beverage, other services — compared between the two systems in the first days.
Occupied rooms, guest count and occupancy for each night.
Receivable balances by partner and total deposits at the cutover point.
Record counts for guest profiles and future bookings.

The rollback plan must be written in advance, not improvised during the incident

State the trigger conditions explicitly: which variance threshold, and which class of incident, means stopping and reverting.
State who has authority to call a rollback, and within what time it must be called.
State the steps back: restoring write access on the old system, handling transactions posted to the new system during that short window, and which departments to notify.
In the migration described at the start of this article, the rollback plan was fully prepared even though it was never needed — and it was precisely because it existed that the team dared to press the button.

Part 8: After go-live — what to reconcile, and for how long

Go-live day is not the finish line. Most genuine discrepancies only surface at the first period close, so the post-go-live monitoring schedule should be fixed at contract signature.

The first day

Run the night audit with a vendor representative present; reconcile the day's revenue against the old system that same night.
Check every occupied room: correct room, correct rate, folio complete line by line.

The first week

Reconcile revenue day by day; review the less common transactions as they first appear: mid-stay room moves, folio splits and merges, partial group settlement, refunds, no-shows.
Check the data pushed to connected channels: online distribution, e-invoicing, residence declaration.
Keep an issue log by department — that is the input for the supplementary training session at the end of the week.

The first month and the first period close

The monthly close is the most important test: revenue by department, output VAT, receivables and remaining deposits must all agree with the accounting ledger.
Reconcile the opening balances entered against the signed receivables confirmations, and verify no variance has appeared.
Review the open-items list in the acceptance minutes and close each one with a specific date.

The first quarter

Compare the operating metrics — occupancy, average daily rate, revenue per available room — against the same period last year, to catch systematic distortions that daily reconciliation misses.
Decide when to end read-only access to the old system and move it to archive, once you are confident routine lookups are no longer needed.
Reassess permissions: only after a few months of real operation do you learn who actually needs which rights.

By the end of the first quarter, the owner should be able to see the whole portfolio on one consistent set of metric definitions — which the complete hotel management solution DiHotel and online AI hotel management software DiCloud provide out of the box for properties in the same ecosystem. The perspective for smaller properties, where the problem is usually moving data from Excel into purpose-built software, is covered in the companion article on the DiCloud Blog.

Considering replacing your on-premise system?

The DiHotel team surveys your hotel's current data, produces the mapping diagram and reconciliation sheet before any contract discussion — with a migration offer: free data migration, bonus months matching the remainder of your old contract and a trial on your own data. Operational commitments: go-live in one day, parallel running, rollback available.

Conclusion

Losing data when replacing software is not fate — it is the consequence of skipping a handful of steps that fit on one page. The ten steps in this article reduce to three principles: agree the scope and take a backup before touching anything; reconcile by the numbers, signed off by the hotel's own people; and always keep a way back through a read-only old system and a rollback plan. On the operational side, remember the two opposite directions: historical receivables carry across only as an opening balance, while in-house folios and future booking deposits must be attached booking by booking.

If the system you run has had no update for a long time, does not keep pace with Circular 99/2025/TT-BTC, e-invoicing and automated residence declaration, responds slowly and publishes no product roadmap, then moving to a continuously developed platform is a risk management decision rather than a matter of technology preference. For the 4–5 star, resort and chain segment, premium hotel management software DiHotel stands behind more than 300 properties in Vietnam and Japan with over twenty years of continuous development; smaller properties in the same portfolio use the all-round hotel management solution DiCloud and still consolidate reporting in one place. Done to process, a migration costs one day; done wrong, it costs a great deal more.

<< Return to blog list