Moving Your Hotel From Excel to a PMS: A Practical 30-Day Plan

Why "just switch on Monday" fails

Most hotels that get burned by a PMS switch didn't pick the wrong software — they picked the wrong week. The front desk team is still finding rooms in a spreadsheet by scrolling, the night auditor closes the day by re-typing totals into another tab, and reservations arrive by phone, WhatsApp and a booking-site email that someone copies into a calendar grid by hand. None of that is written down as a process, so nobody notices how much tribal knowledge lives in one person's head until that person is on leave during go-live week.

A hotel software migration is really two projects: moving the data (rooms, rates, open bookings, balances) and moving the habits (who checks in a walk-in, who authorises a discount, who closes the day). Skip the second one and the PMS will be technically correct and practically ignored — staff will keep a shadow spreadsheet 'just in case', and that shadow spreadsheet becomes the real system of record within a week.

This plan treats the switch as a 30-day project with four phases: prepare data (days 1-15), run parallel (days 16-25), go live (day 26), and stabilise (days 27-30). Compress it if you're small and simple; stretch phase 2 if you run a large property with complex rate structures. The order matters more than the exact day count.

Days 1-15: what data to prepare, in the right order

Data has dependencies. Room types depend on nothing; rate codes depend on room types; reservations depend on rate codes and companies; opening balances depend on reservations. Build in that order or you will spend days re-entering the same reservation because the rate code it needed did not exist yet.

1. Rooms and room types. List every physical room with its number, floor and room type (Standard, Deluxe, Suite...). Decide room-type capacity (max adults/children) and any rooms that are permanently out of service — enter those as out-of-order from day one so nobody sells them by accident.
2. Rate codes. For each room type, list the selling rates you actually use: BAR/rack rate, corporate rates per company, OTA rates, seasonal rates, and any package rates (bed & breakfast, half board). Write down what each rate includes — this is the step hotels skip, and it is the one that causes billing disputes in week one.
3. Companies and travel agents. Pull your list of corporate accounts and agents with active contracts: name, tax/registration details if you invoice them, credit terms, and the rate code each one gets. This becomes your city ledger set-up.
4. Open reservations. Export or list every reservation with a check-in date on or after go-live, with guest name, dates, room type, rate, and any deposit already taken. This is usually the longest list — budget real time for it, not a guess.
5. Opening balances. For every in-house guest and every company with a running account, freeze the balance as of the night before go-live: what they owe, what they've paid, what's already invoiced. This single number is where most migrations go wrong, because it is entered once, under time pressure, and rarely double-checked.
6. Chart of accounts and tax setup. If you're also formalising double-entry accounting for the first time, agree the account codes for room revenue, F&B revenue, taxes and payment methods before go-live, not during it.

How do you run a parallel run without doubling everyone's work?

A parallel run means the front desk keeps using Excel as the real system while a small team enters the same day's activity into the PMS, side by side, for a defined window — not forever. The point isn't to duplicate every transaction for a month; it's to catch the mismatches that only show up with real guests: a rate that doesn't total right, a tax that's calculated differently, a report that a manager relies on that doesn't exist yet in the new system.

1. Pick 7-10 days, not 30. Longer parallel runs don't catch more problems — they just tire out the team that's doing double entry.
2. Assign one or two people to the parallel entry, not the whole front desk. Everyone else keeps working the spreadsheet as normal.
3. At the end of each parallel day, compare three numbers: total room revenue, total cash/card collected, and the count of in-house guests. If all three match, the day is clean. If one doesn't, find out why before the next day starts, not at month end.
4. Track every mismatch in one shared list with a reason, even the ones you decide not to fix. That list becomes your go-live risk register.

Training staff by role, not as one big session

A four-hour training day for everyone produces four hours of half-attention, because a night auditor does not need to know the housekeeping board and a cashier does not need to know channel manager mapping. Split training by the tasks each role actually performs, and keep each session under 90 minutes with the person doing the clicking, not watching a demo.

Give each role a one-page cheat sheet with the exact clicks for their three or four most common tasks, printed and taped near the workstation for the first week. Nobody remembers a training session under real pressure with a guest waiting; they remember a laminated card.

Go-live day: the checklist that prevents a bad first day

Go live on your lowest-occupancy day of the week if you have a choice, never on a day with a group arrival or an event. The goal of day one is a boring, uneventful shift — not a stress test.

1. Confirm opening balances were entered and independently checked (see the note above) — do not go live on unverified balances.
2. Confirm every open reservation from the export is in the system, spot-check 10% of them against the original booking source.
3. Freeze new bookings in Excel as of a fixed cut-off time the night before; anything after that time goes straight into the PMS.
4. Have the vendor or your PMS admin on call for the first shift, not just reachable by email.
5. Print a physical arrivals and in-house list as a backup for the first shift, in case anyone loses confidence in the screen mid-check-in.
6. Run the night audit on schedule on night one even if occupancy is low — the first audit is where configuration gaps in tax or rate posting usually surface.

First week: what to check every day

The first week is not 'done, move on' — it's when small configuration errors turn into real discrepancies if nobody is watching. Assign one person, usually the GM or the accountant, to check the same three things every single day for the first seven days.

• Does total room revenue for the day match the sum of individual folio charges? A mismatch usually means a rate code or tax setting.
• Does the cash/card total collected match what physically went into the drawer and the card terminal? A mismatch here is often a training gap, not a software bug.
• Are opening balances for in-house guests behaving correctly as they check out — no guest showing a balance that doesn't match what they were told at check-in?

By day seven, if those three numbers have matched daily, you have a stable system and can safely widen who checks what to your normal reporting rhythm. If they have not matched, you still have a live, current export from the parallel run to compare against — which is exactly why the parallel run mattered.

A note on doing this with Mukeem

Mukeem is built for exactly this kind of migration in Egyptian and regional hotels: reservations, front desk and accounting share one data model from the first entry, so a room type, a rate code and a company only need to be set up once and they're consistent everywhere — the folio, the night audit and the city ledger all read from the same numbers instead of three separate exports that have to be reconciled by hand.

None of that changes the plan above. Data still has to be prepared in order, a parallel run still catches real-world mismatches before they cost you money, and staff still need role-based training with a cheat sheet on the desk. Software shortens the list of things that can go wrong; it doesn't remove the need for a plan.