Migrating data from Excel to hotel management software: a step-by-step guide

Last time we looked at how to vet a software vendor before signing a contract. This time we take a very practical next step — and address the biggest worry a small hotel owner has when facing a system change: where does my data go, will I lose any, how long will it take, and if it goes wrong how do I get back? This article is not about features. It is a concrete migration process — what to clean, what to move, at what level of detail, how to verify it, and which figures must never be lumped together.

To be fair from the outset: the spreadsheet is not the enemy. For an 8-room property with one person on duty and guests booking by phone, a spreadsheet does nearly everything well — and for free. The problem is not the tool, it is the threshold of scale. Past that threshold, the very file that saved you money starts quietly costing you. Most of what follows is here to help you work out which side of the threshold you are on, and if you have crossed it, to get through the migration under control.

Part 1: The risks of running a hotel on Excel

The risks below are not theoretical. They are the situations our implementation team meets over and over when taking data from properties running on spreadsheets. What they share: each looks trivial on the day it happens, and only surfaces once it is too late.

1. Losing the file — a one-off risk with total damage

• The file lives on the front-desk computer or a USB stick. A failed drive, a malware infection, a borrowed laptop that walks away — and the entire business history disappears in one morning.
• Backing up by "copying it somewhere else now and then" means the copy is always days or weeks behind reality, and nobody is certain which version is the latest.
• Parallel versions — aug_ledger, aug_ledger_new, aug_ledger_final — produce the situation where two people are both right, according to two different files.

2. Broken formulas that raise no error

• You add a booking row at the bottom of the table but the sum formula only reaches the row above: the total still shows a tidy number, just an incomplete one.
• A formula dragged one cell off, an absolute reference lost, a numeric cell stored as text — the spreadsheet says nothing. This is the biggest difference from a system with data constraints: a spreadsheet always returns a result, even when the result is wrong.
• The knock-on effect: if revenue is recorded wrongly, then occupancy, average rate and every pricing decision next month drift with it.

3. Nobody knows who changed what

• An amount is altered, a booking row vanishes — the file keeps no record of who did it, when, or what the value was before.
• This hurts both sides. The owner cannot trace the cause, and staff who did the right thing have nothing to prove it with. We covered this at length in controlling hotel revenue leakage.

4. No remote access, no simultaneous access

• An absent owner has to message for the numbers. What comes back has been summarised by hand — meaning it has already passed through one layer of interpretation.
• Putting the file on a cloud storage service does give remote access, but two people editing at once still produce a conflicted copy — and the conflicted copy usually gets resolved by picking one at random.

5. Double-booking

• This is the costliest risk, in money and reputation. A spreadsheet does not know which period a room is already occupied for — it is only cells of text and numbers. Whoever enters data has to remember and cross-check by hand.
• The risk jumps the moment you start taking guests from several channels at once: phone calls, messages, online bookings. Three booking sources, one file, no lock against collisions.
• The cost of one double-booking is not just moving the guest to another property — it is the bad review left on the sales channel, which affects revenue for months afterwards.

6. What a spreadsheet simply cannot do

• Residence declaration to the authorities has to be retyped by hand for every stay.
• There is no way to look up how many times a guest has stayed, which room they prefer, or what they still owe.
• E-invoices cannot be issued straight from the data you hold; it has to be keyed a second time into other software — and every re-entry is another chance to introduce an error.

Part 2: How general retail software differs from purpose-built hotel software

When the spreadsheet runs out of road, many owners reach for the nearest option: general point-of-sale software — built for shops or restaurants, with a "hotel" section bolted on. That handles taking payment and printing receipts, but leaves the core of accommodation operations empty. The difference is not in the interface; it is in the nature of what is being sold.

Retail sells an item; a hotel sells a room-night

• A shop sells an item: deduct one unit of stock, take the money, done. A hotel sells the right to occupy a room for a period of time — the same room is resold countless times for countless different nights.
• So a hotel's "inventory" is a two-dimensional calendar (room × date), not a stock count. Retail software has no such structure, which is why it cannot block double-bookings by itself — precisely what you were trying to escape by leaving the spreadsheet.
• Room revenue has to be recognised spread across each night of the stay, not dumped onto the checkout date. Dump it and every daily metric is wrong, even when the monthly total is right.

The folio — an open bill spanning several days

• A retail receipt opens and closes within minutes. A guest's folio stays open from check-in to check-out, accumulating the room rate each night plus every service charged along the way.
• A folio must split and merge: the company pays the room while the guest pays their own drinks and laundry; two people sharing split the bill; a group consolidates onto one bill while still keeping the detail per room.
• Line items must be transferable between folios while keeping a trace of who moved them and when — this is daily desk work, not a rare edge case.

Charging back to the room

• A guest has breakfast in the restaurant, signs for it, and the charge flows straight to the room folio to be settled once at check-out. Retail software has no concept of "sign it to the room" — it wants payment at the point of sale.
• Without that mechanism, the reality at the desk is: write it on paper and key it in that evening. You left the spreadsheet to avoid manual entry, and you are back at manual entry.

Future bookings and deposits

• A guest books today for a holiday three months away and transfers a deposit. That money is not revenue today — it is a sum the hotel is holding, to be offset against that particular stay's bill or refunded under the cancellation policy.
• Retail software records incoming money as revenue immediately. The distortion grows with the season: in peak booking periods the reports look wonderful, and when the guests actually arrive revenue appears to "fall short" for no explicable reason.

Residence declaration and guest profiles

• Accommodation is an industry legally obliged to declare guest details to the authorities. A purpose-built system captures ID details at check-in and files the declaration from that same data, with no second keying.
• A guest profile also has to link to stay history, room preferences and receivables — none of which a retail-style customer list holds.

Operations only hotels have

• Night audit: closing the business day, automatically posting the room charge for every occupied room, and rolling over to the new date.
• Room and housekeeping status: clean, dirty, being cleaned, inspected; out-of-order (OOO) rooms awaiting repair and out-of-service (OOS) rooms are treated differently when calculating occupancy.
• Edge cases: mid-stay room moves, early departures, no-shows, late check-out with a surcharge, stay extensions. Each has to compute the right amount for the right night.
• Two-way sync with online sales channels: sell a room here and inventory on every other channel must drop within seconds.

This is exactly why a total hotel management solution exists as its own software category rather than as a small section inside a retail package. Not because it has "more features", but because it models correctly what a hotel is actually selling.

Part 3: Signs a small hotel needs to change software

Instead of a vague sense that "it's probably time", use the countable criteria below. Implementation experience shows that once you hit three or more of these signs, the hidden cost of keeping the old way already exceeds the cost of software.

Signs of scale

• Beyond roughly 15–20 rooms. Below that, one person can hold the whole calendar in their head; above it, memory becomes the weak point of the system.
• A second property. Two files for two properties means never having a trustworthy consolidated figure in real time.
• The data file passes a few thousand rows, opens slowly, has to be split by year, and nobody dares delete an old sheet for fear of breaking a formula.

Signs about people

• Two or more people entering data, or a night shift. This is the most important sign — every problem with data conflicts and missing audit trails starts here.
• The owner is not on site daily and has to ask for numbers by message.
• New staff joining: training someone on a home-made file always takes longer than training them on a system with a clear process.

Signs in the business

• You start selling through online channels. This is the decisive line: from this point, updating inventory by hand is a permanent double-booking risk.
• At least one double-booking in the last three months. Once is an accident; twice is a systemic signal.
• Receivables appear with companies, agents or groups — meaning you need debt ageing, not just cash in and out.
• E-invoices and residence declarations are needed regularly, often enough that retyping consumes real time.
• You want to know your average daily rate and revenue per available room but cannot keep up by hand — while these are the two metrics that decide whether your pricing is right.

If you run a mini hotel, a guesthouse or a few homestay units and recognise yourself in most of the signs above, what you need is purpose-built cloud hotel management software — not a better spreadsheet, and not retail software with a rooms section added. We analysed what is specific to each of these models in mini hotels, guesthouses and homestays.

Part 4: Preparing data before the move — what to clean, what to keep

Most migration incidents do not originate during the load; they originate earlier, in preparation. Machines load exactly what they are given; feed in a mess and the new system becomes a tidier copy of the old mess. This is also the part only the owner can do — no implementation team knows which row is real and which was a test entry.

Mandatory preparation steps

• Back up the original and lock it. Before touching a single cell: copy every existing file to its own folder, name it with the date, and set it read-only. This is the anchor every later argument can return to.
• Fix a cut-off date. Pick a clear point — usually the first day of a month — as the boundary: before it belongs to the old books, from it onwards to the new. Without this, nobody knows where a transaction belongs.
• Appoint one person responsible for the data. One person alone has the authority to declare "this row is correct". Several people cleaning one file together is the fastest route to three versions of the truth.

What to clean

• Room list: one unique code per room, no duplicates, no changes midway. State the room type, standard occupancy and maximum occupancy. Drop rooms that have been demolished or repurposed.
• Rate table: the most commonly overlooked item, because in many properties the rates live in the owner's head rather than on paper. Write them out: published rates by room type, contract rates per partner, extra-person supplements, child policy, weekend and peak-season rates.
• Guest profiles: de-duplicate by ID number or phone number. Standardise formats — keep the leading zero on phone numbers, one single date format, names capitalised consistently. Delete test rows like "test guest" or "aaa".
• Partner list: companies, agents, groups. Merge duplicate records with differently spelled names. Partners inactive for more than two years with no outstanding balance stay in the archive and are not brought over.

What to keep — and where

• Bring to the new system: all lists and rate tables; guest profiles; future bookings; in-house guests; receivable balances as at the cut-off date.
• Keep for reference, don't migrate: detailed transaction history from previous years. For daily operations the last 12–24 months is more than enough; anything older sits in a read-only archive, opened when needed.
• Do not migrate: duplicate rows, test rows, personal notes inside cells, and any information currently conveyed by cell colour — because colour does not transfer. If your yellow cell means "deposit paid", add a column that says "deposit paid" in words before migrating.

Format of the handover file

• One sheet per data type; the first row is column names; data starts on the second row.
• No merged cells, no sub-heading rows inserted mid-table, no total rows sitting among the data rows.
• One value per cell. A cell reading "0901xxxxxx / Ms Hoa / pay later" must be split into three columns.
• Number columns hold numbers, date columns hold dates — no text mixed into number columns ("unclear", "check again").

Part 5: Migrating the data step by step

The order below is not optional. Each step is the foundation of the next: without the room list you cannot attach bookings; without guest profiles you cannot attach folios; without partners you cannot record receivables. After each step, stop and reconcile before moving on — catching a discrepancy at step two is far cheaper than catching it at step five.

Step 1 — Rooms, room types and rate tables

• Load room types first, then rooms, then the rate tables attached to each type.
• Check immediately: the total room count in the new system must exactly equal the rooms actually in service. Being one room out at this step will distort occupancy forever afterwards.
• Create a dummy booking in each room type to see whether the rate that appears matches the table you just loaded, then delete it.

Step 2 — Guest profiles and partners

• Load the de-duplicated guest list and the list of companies, agents and groups.
• Check immediately: records in the new system against rows in the cleaned file. Any gap must be explainable by rows removed as duplicates, not left as a mystery number.
• Search for a few regulars by name and by phone number to confirm Vietnamese diacritics and number formats have not broken.

Step 3 — In-house guests and open folios

• This is the most sensitive group, because these guests will check out on the new system. Every in-house guest must be migrated with the right room, arrival date, expected departure date and rate.
• Charges already on the folio (room charges for nights stayed, services signed to the room, prepayments) migrate as individual detail lines, never collapsed into a single "provisional" line.
• Check immediately: stand at the desk, open the new system's room map and compare it by eye with reality, floor by floor.

Step 4 — Future bookings and deposits

• Every booking from the cut-off date onwards must move to the new system, with its source, agreed rate and cancellation policy.
• Deposits attach to specific bookings — never pooled into one lump. A deposit is an obligation to an identified guest on an identified date. (Unallocated deposits with no identifiable owner are handled per Part 6.)
• Check immediately: open the next 60 days and reconcile, day by day, how many rooms are sold against the old spreadsheet. This is the single most important reconciliation of the whole migration.

Step 5 — Receivables

• Partner receivables migrate as an opening balance, following the principle set out in Part 6.
• Check immediately: the total balance in the new system equals the total on the signed receivables confirmation.

Step 6 — Remaining opening balances

• The cash float at the desk and the balance of the account used for the property's operations as at the cut-off date.
• Vouchers, gift certificates and nights sold but not yet used — these are obligations to guests; miss them and you lose money when the guest returns to claim.
• Check immediately: count the actual cash at the desk at the end of the cut-off day and compare with what was loaded.

Part 6: "Close the old books, open the new" — the rule for receivables and deposits

This is the part that decides whether a migration is tidy or drags on for months. The rule is short: close the old books, open the new. But it applies in two opposite directions for two kinds of money, and this is exactly where it usually goes wrong.

Historical partner receivables: migrate the balance only

• Do not migrate invoice-by-invoice, receipt-by-receipt detail from previous years. For each partner, move exactly one opening-balance line as at the cut-off date.
• Attach to that balance a detailed schedule — listing the documents that make it up — and a receivables confirmation signed by both parties.
• Keep the old system read-only for 3–6 months so you can look things up when a partner queries a specific invoice. After that period, all real queries have been settled.
• Why do it this way: migrating years of receivables detail is the most time-consuming and error-prone stage of any migration — the older the data the less standardised it is, and nobody has the authority to certify each line. Meanwhile, what carries real legal and operational weight is the final figure both parties signed, not the path that led to it.

In-house folios and deposits: detail is mandatory

• In the opposite direction, folios of in-house guests and deposits on future bookings must be migrated attached to each individual booking. Never collapsed into a total.
• The reason is concrete: in-house guests will check out on the new system. If their folio is only a total, the desk cannot issue a correctly itemised bill, cannot separate the company-paid portion from the guest-paid portion, and cannot resolve a query about one charge.
• The same holds for deposits: a pooled deposit cannot offset itself correctly against the bill of a guest who booked three months earlier. The deposit has to sit on that person's booking.

The case of deposits with no identifiable owner

• In practice there is always a small group: holding deposits already received but pooled in one place under the old records, no longer traceable to a specific guest or room.
• The rule: any deposit you can confidently tie to a guest and a booking attaches directly to that booking; any unallocated deposit must not be arbitrarily assigned to some booking — carry it over as a liability of the hotel, recorded one line per amount with a detailed schedule on the accounting side.
• This preserves two important things at once: the guest's money does not vanish from the books, and when the guest returns to claim it you can still trace where the amount came from.

Part 7: Parallel running and rollback — why you don't burn the bridge

A well-designed migration always has a way back. Not because whoever is doing it lacks confidence, but on principle: any system can meet an unforeseen situation, and a hotel does not have the option of pausing room sales while it is resolved. The three protective layers below should be agreed in writing before you start.

Layer 1 — Keep the old system intact, read-only

• Do not delete, do not tidy, do not "take the chance to clean it up" — leave the old file alone. Freeze it exactly as it stands at the cut-off date and make it read-only.
• Keep it at least 3–6 months. It is the only reference when a dispute arises, and keeping it costs virtually nothing.

Layer 2 — Run in parallel for a short period

• Parallel running does not mean double-entering everything — at a small property, making reception key into two places is the fastest way to get both places wrong and the whole team demoralised.
• What works in practice: from the cut-off date, all operations are entered only in the new system. Alongside that, for the first 3–7 days, spend fifteen minutes at the end of each day reconciling three numbers against the old records: revenue for the day, rooms occupied, arrivals and departures.
• If those three numbers match for a week straight, you can relax. Where they diverge, you catch it the same day, while everyone still remembers what happened.

Layer 3 — Rollback by batch

• Every data load is tagged as its own batch. If a batch turns out to be wrong, remove the whole batch and return the system to its exact pre-load state, rather than hand-correcting record by record.
• The condition for a clean rollback: no new transactions have been written over that data yet. Which is why reconciling right after each step in Part 5 is not a formality — it is what keeps the rollback door open.

Choosing the right moment

• Pick a low-occupancy weekday; avoid peak season, weekends and public holidays.
• Align it with the start of an accounting period so the books are not cut mid-period.
• Train the team before the switch, not during it. The night shift needs its own session, because they are the first to run the night audit on the new system.

Part 8: After the move — what to check so you trust the numbers

Finishing the move is not the end. A migration only counts as successful once you can verify for yourself that the numbers in the new system are right — by your own actions, not by the implementer's assurance. Here are three rounds of checks over time.

On go-live day itself

• Physical reconciliation: open the room map on your phone and walk the floors. Any room shown as occupied must actually have a guest in it.
• Run one complete process end to end: create a booking → check in → charge a service to the room → move to another room → check out → issue the invoice. The whole chain must run without a snag, and the final amount must be right.
• Try a residence declaration for one stay to confirm the ID data came across completely.
• Check permissions: log in with a reception account and see whether it can view things only the owner should see.
• At end of day: count the actual cash at the desk and compare it with the cash revenue the system recorded.

During the first week

• Three numbers a day: revenue, rooms occupied, guest movements — reconciled against the old records as described in Part 7.
• The next 60 days: review them once more, especially peak dates that are nearly sold out. This is where one missed booking does the most damage.
• Total deposits in the new system match the cash book and bank statements.
• Total receivable balances match the confirmation signed in Part 6.
• The night audit runs cleanly several nights in a row, with room charges posted automatically and correctly for every occupied room.

After the first month

• Reconcile the monthly report from the new system against the old way of totalling. Any difference must be explainable by a specific cause — usually that the old method dumped revenue on the checkout date while the new system spreads it per night. That is a correct difference, not an error.
• Review the operating metrics: occupancy, average daily rate, revenue per available room — available for the first time without hand calculation.
• Sign the migration acceptance record, stating the scope of data migrated, the reconciliation results, and the end date of the read-only retention period for the old system.

When these rounds of checks pass cleanly, you don't just have new software. You have a set of numbers you can trust — and only then does everything that follows, from room pricing to monitoring the property remotely, have something to stand on. That same data foundation is what lets you later extend into the other parts of DiCloud, our cloud AI hotel management software: multi-channel room sales, an automated guest-response assistant, or owner reporting on a phone.

Conclusion

Migrating from a spreadsheet to purpose-built online hotel management software is not a gamble, provided you follow the sequence: clean the data and fix the cut-off date first, migrate in six groups and reconcile after each, apply close the old books, open the new to historical receivables while keeping full detail for in-house guests and deposits, keep the old system read-only, and always have a rollback. The fear of losing data is legitimate — and the answer to it has to be a verifiable process, not a promise.

For mini hotels, guesthouses and homestays, the threshold for leaving the spreadsheet usually arrives earlier than owners expect: around 15–20 rooms, two people entering data, or the first day of selling through an online channel. From that point, properly built guesthouse management software and mini hotel management software gives you back the most valuable thing of all: confidence that the number you are looking at is the real number. As a property grows into a chain or up to 4–5 star standard, the same philosophy of clean data at source continues at a higher tier with DiHotel, the AI hotel management software, and hotel chain management software — where migration is many times more complex, and you can preview the system migration checklist for 4–5 star hotels in the companion piece on the DiHotel Blog. And if you want to understand more about the platform all your migrated data will sit on, read about DiCloud, the online AI hotel management software, and homestay management software in the DiHotel Solutions ecosystem.