Switching channel managers without losing bookings: a cutover checklist

A channel manager is the software that pushes a hotel's rates and availability to booking sites and pulls reservations back. Switching it safely means rebuilding every room-type and rate-plan mapping, moving one channel at a time, checking sample dates after each move, and reconciling bookings daily for the first 72 hours.

The dangerous hour in a channel manager switch is not the one where the new system goes on. It is the hour when the old system is still pushing yesterday's availability while the new one is half mapped, and a guest books a room you thought was closed. This article walks through the whole switch: what breaks, what to settle with the old provider, how to build the mapping sheet, the order of the moves, verification after each one, the first 72 hours of reconciliation, and how to close the old connection cleanly.

What actually breaks when you change channel managers?#

The connection breaks in four places: mappings, rates, restrictions and the return path for reservations. Each fails differently, and each is fixed before the switch rather than after it.

First, the pipe itself. The channel manager sits between the hotel's own system and the booking sites. It pushes rates, availability and restrictions outward, and pulls reservations inward. The reservation does not live in the channel manager; it lives on the booking site and in the hotel system. That is why a switch is a mapping and timing problem, not a data migration.

Mapping failure comes first. A room type or rate plan that exists on one side and not the other is silently dropped, so the channel keeps selling an old version of the room. Rate failure follows: a rate plan mapped to the wrong occupancy or board type sells a double room as a single, or breakfast at no charge. Restriction failure is the dangerous one, because stop-sale, minimum stay and closed-to-arrival do not travel with the rate; a restriction that fails to push reopens dates the hotel closed. Return-path failure is the silent one: reservations come back by a different route than rates go out, so a booking can exist on the channel and never reach the hotel.

Then there is the overlap problem. While both systems are connected to the same channel, the last write wins, and nobody can say which system wrote last. Before anything is switched, name one accountable person and one deputy, because every check below needs a signature.

What must be settled with the old provider before you give notice?#

Four things in writing: the notice period, the last day the connection stays on, the data you are entitled to export, and who pays for the overlap. Settle them before the notice email, not after.

Read the notice period and the contract end date first. A switch planned without them lands in a paid month nobody budgeted for. Ask directly whether the connection can stay active until a named date, and whether it can be extended by a week if the switch slips.

On data export, ask for reservations with guest details, rate and restriction history, mapping tables, channel message threads and invoices. Ask for a machine-readable file, not a PDF. Ask specifically what happens to reservations already received by the old system but not yet delivered to the hotel. And confirm in writing that after the end date the old system stops pushing rates and stops pulling reservations.

Ask the new provider which channels need credentials or approval from the site itself, and who is expected to hold them. Procedures differ by site, so get the answer in writing from both sides. These are among the questions to ask before you sign a channel manager contract. Keep the exit clause and the export confirmation in the same folder as the mapping sheet and the switch log.

How do you build the mapping sheet before the switch?#

One row for every combination of channel, room type and rate plan, with the sample dates you will test and the name of the person who confirmed it.

The columns: channel, room type in the hotel system, room type on the channel, rate plan and board, occupancy, restrictions used, currency, sample dates, confirmed by, date confirmed. List the room types and rate plans you deliberately do not sell on a channel, so nobody maps them by accident during setup. Record which restrictions each channel supports and whether the new system can express them; a restriction the new system cannot send is a decision to make now, not a surprise to discover later.

Pick sample dates that cover the awkward cases: a near date with availability, a sold-out date, a date closed to arrival, a date with a minimum stay, a far date, and a date with a package. Two people check the sheet: the person who built it and the person who will confirm each switch. Keep it as a living document; it is also the record you will reach for when a rate goes wrong three weeks later. The mechanics of room types, rate plans and testing deserve their own read.

For example, the standard double row carries sample dates covering a sold-out Friday and a minimum-stay weekend, confirmed by the reservations manager; the family room row covers a far date with a package, confirmed by the revenue manager.

In what order should you switch the channels, and who confirms each step?#

One channel per day, in order of increasing booking volume, on a weekday morning when the reservations team is on duty, with a named person confirming each step.

Why not all at once: if two channels fail together you cannot tell which mapping caused it. Start with the channel that carries the fewest bookings and the simplest mapping, so the first day is a rehearsal. Save the largest channel for when the mapping is proven and the team is fresh.

Each step has three parts: turn off the old push for that channel, turn on the new push, then verify. The same person signs all three. Keep a switch log: channel, time off, time on, who did it, what was checked, what was found, what was changed. If a channel cannot be switched cleanly, stop and go back; the old connection is still running for every channel you have not moved yet. The discipline is the same as a PMS cutover plan, applied one channel at a time instead of one night.

How do you verify rates and availability after each switch?#

Search the switched channel as a guest would, on the sample dates from the mapping sheet, compare what you see with what the hotel system says, then test the return path with a real booking you cancel afterwards.

Check the guest view, logged out, in the currency the channel shows to that market, not in the back office. Compare rate, room type name, occupancy, board, cancellation policy, and the taxes and fees shown at checkout. Test a stop-sale: close one date in the hotel system, wait for the push, confirm the channel shows it closed, then reopen it and confirm that arrives too. Test a rate change the same way, and test a restriction you actually use, such as a minimum stay.

Test the return path with a real booking on the channel for a far date. Confirm it appears in the new channel manager and in the hotel system, then cancel it on the channel and confirm the cancellation arrives as well. Write down the time of every check; pushes are not instant, and a check made too early proves nothing. If a channel shows a rate you did not send, find out whether the old system is still pushing before you change anything else.

What does the first 72 hours of reconciliation look like?#

Three lists compared once a day: reservations in the new channel manager, reservations in each channel's own extranet, and reservations in the hotel system. Every difference is explained the same day.

Why three lists: the channel manager can lose a booking the channel still holds, and the hotel system can hold a booking the channel manager never received. Run a morning check before the arrivals list is printed, and an evening check before the night audit closes the business day. Compare count, guest name, arrival and departure, room type, rate and status, including modifications and cancellations.

The orphan case is a guest at the desk with a channel confirmation and no reservation in the hotel system. Book them in from the channel confirmation first, then find where the path broke. The double case is the same room sold twice because a stop-sale never arrived; prevention sits in the mapping and the verification, not in speed at the desk, and overlaps with the causes of double bookings across channels. One person reconciles and a second signs off. Keep reconciling at a lower frequency after 72 hours until the first full week closes clean.

How do you close the old connection and keep the records?#

Get written confirmation that the old system has stopped pushing rates and pulling reservations, export everything you are entitled to, and keep both in one archive with the mapping sheet and the switch log.

Confirm per channel, not per contract: the old provider may have switched off some channels and left others running. Export reservations with guest details, rate and restriction history, mapping tables, channel message threads and invoices, in a format you can open without the old system. Ask for read-only access for a defined period if the contract allows it, and ask before the final invoice is paid rather than after. Check that invoice against the exit terms you settled before notice.

Store the archive where the reservations team can reach it; the first question after a switch is usually about a rate or a booking from last season. Keep the old mappings as a record, not as a template: they describe a system you no longer run. Treat the hotel system's own data with the same discipline when it is the thing being replaced, as covered in PMS data migration.

What to do next#

Build the mapping sheet and open the switch log this week, before any notice is given. Once those two documents exist, the switch becomes a sequence of small, signed, reversible steps instead of one nervous night, and every later question about a rate or a booking has a written answer.