When an OTA Redesigns Its Extranet: A Rate-Plan Migration Checklist
An OTA redesign moves the fields your rate-plan mapping points at, and it does so without telling you. This guide separates the three layers a redesign changes, gives a five-item check to run before the switch, lists what to capture before the old interface disappears, and sets out the three things to verify once the new one is live.
A redesign isn't cosmetic. It's the moment the field your mapping pointed at quietly stops existing.
Last updated: September 23, 2026
A channel announcing a new admin interface isn't asking you to learn new menus; it's moving the things your rate-plan mapping points at. The dangerous part is that nothing fails loudly. A mapping that no longer resolves doesn't return an error. It returns a price — the channel's own, on a night you thought you controlled. This guide separates the three layers a redesign actually changes, and gives five checks to run before the switch. It lists what to capture before the old screens disappear, and sets out the three things to verify once the new interface is live.
Key Takeaways
- Three layers move, two of them matter. Labels are noise; the data model and the fallback behaviour are the risk.
- Twenty minutes before, not a day after. Five checks while the old interface still answers questions.
- Photograph before it goes. A field name without a picture becomes a guess within a month.
- Verify as a guest, not as a host. What you pushed and what the guest sees are different numbers.
- Date every row you touched. A migration without a record is a migration you cannot audit.
What actually changes in a redesign, and which changes affect a mapping
Every redesign changes three things at once, and only two of them are worth your attention.
The surface. Labels, menus, icons, where a screen sits. This is what the announcement email describes and what everybody complains about. It doesn't break anything, because a mapping points at an object, not at a button.
The model. Where things live relative to each other. A cancellation policy that used to sit inside the rate plan may move beside it. A plan that used to belong to a unit may now belong to a unit-and-occupancy pair. A promotion that used to be part of the rate may become a layer applied afterwards. This is the layer that breaks mappings, because the address your row points at has changed shape.
The fallback. What the channel does when a value it expects is missing. If a plan you reference no longer exists, does the push fail, or does the channel file the rate against a default? If a conversion the channel used to perform is withdrawn, is your number published as sent, or silently adjusted? This is the layer that produces wrong prices rather than error messages, and it's almost never mentioned in the announcement.
The second and third layers are why a redesign needs a procedure rather than a sigh. One vendor's help documentation, dated 2026-09-17, records that an automatic markup conversion tied to one platform's single-sided fee structure was withdrawn. Treat that as one party's published claim rather than a rule, and check what your own portal currently does before you rely on it. The general lesson is the one that matters: when a conversion stops happening, the number you send and the number that gets published stop being the same number. And nothing tells you.
Three fields move most often and are worth watching in any redesign:
| Field | Where it moves to | What it does to your mapping |
|---|---|---|
| Cancellation terms | Out of the plan, into a separate policy object | Editing the plan no longer moves the terms |
| Occupancy basis | Into the unit-and-rate pair | One plan becomes several, one per occupancy level |
| Promotions and discounts | A layer above the rate | The published figure is no longer the figure you pushed |
A five-item pre-migration check you can run in twenty minutes
Run this while the old interface still exists, because half of it depends on being able to read the current state.
One, walk the mapping table. For every row, open that channel's admin and confirm the target still exists under exactly that label. A renamed or archived target is the single most common casualty of a redesign, and it produces the quietest failure.
Two, confirm the rate basis. Per night, per occupancy, or tiered by length of stay, as the portal shows it today. If this changes during the migration, every price you hold becomes ambiguous rather than wrong, which is harder to spot.
Three, locate the cancellation terms. Inside the plan or beside it. Write down which, because if they move during the migration your plan edits will stop reaching them and you won't notice for a season.
Four, check what can layer on top. Promotions, member pricing, any discount the channel applies after your push. Anything here means the published price has never been solely yours, and a redesign is when you find out how much of it wasn't.
Five, take a baseline. Pick one date about two months out, on one unit, and record what each channel publishes for it today, read as a guest would see it. Without that line in your notes you have nothing to compare against afterwards. Every post-migration difference becomes a matter of opinion.
What to photograph and write down before the old interface disappears
The old interface is evidence, and once it's gone you can't reconstruct it. Capture it before the switch, in one folder named with the date.
Screenshot five screens per channel. The plan list, showing every label exactly as written. The detail page of your most complex plan, including every tab. The restrictions screen, with minimum stay, maximum stay and closed-to-arrival days. The fee and tax screen, showing what is inside the rate and what is added at checkout. And the cancellation policy screen in full.
Alongside each screenshot, write down the things a picture doesn't preserve well. The exact label strings, character for character. The occupancy basis and the currency, including how the figure is rounded. Whether taxes sit inside the rate or on top of it. The support route for that channel and any account reference you need to quote when you open a ticket.
Two reasons this is worth twenty minutes. The first is reconstruction: if a mapping breaks, the screenshot tells you what the mapping was pointing at, which is the question you'll otherwise spend an afternoon answering from memory. The second is evidence: a price dispute with a channel is settled with what the screen showed on a date, and the party holding the screenshot usually wins.
Keeping one record per channel is far easier when all four sit in one place. Each connected channel's source rate and source status show on one row at localsbnb.com. So the baseline you capture has somewhere to live that you'll actually look at again.
The first three things to verify after the migration goes live
Verify in the guest's order rather than yours, because the failure modes are guest-facing.
One, does every row still resolve. Walk the mapping table again and confirm each target exists under the new interface. Anything that no longer resolves is a plan mapped to nothing, and it's currently publishing a price you didn't choose.
Two, does the published price match your baseline. Compare the test date against what you recorded. An identical figure is a pass. A different figure needs an explanation you can state in one sentence — a fee moved inside the rate, a conversion stopped, a promotion started layering. A difference you can't explain isn't a difference to accept; it's a ticket to open before the next guest books it.
Three, can a guest finish the booking. Not "is the night open" but: does the night carry a price, does the minimum stay let the dates through, and does the total at checkout match what you expect after fees and taxes. A migration that leaves availability intact and breaks the booking path is invisible from the calendar. And obvious to the guest.
Then write the date into the last-verified column for every row you touched, and add one line noting which interface version you verified against. The next redesign will ask the same questions, and a table with dates answers them in minutes.
FAQ
Should I rebuild my rate plans from scratch after a redesign?
No. Rebuild the mapping rows, not the plans. Your plans encode decisions you made deliberately; what broke is the address they point at, and remapping is faster and safer than recreating a year of pricing decisions under time pressure.
What if the new interface uses words I have never seen?
Map from behaviour, not from vocabulary. Find out what the new object does — what it changes when you edit it, and what a guest sees — and map to that, whatever it's called. Labels differ by region and account and change again later.
How do I know whether a price difference is mine or the channel's?
Compare against your baseline first. If the figure changed on all four channels together, the cause is on your side. If it changed on one, it's that channel's model or fallback — and the screenshots you took are what let you prove it.
A redesign is a mapping event wearing a design announcement. Run the five checks while the old screens still answer questions, and photograph them before they go. Then verify resolution, published price and the booking path in that order. Nothing here needs to happen twice if you date every row you touch — and the four channel rows you have to watch sit side by side at localsbnb.com.
Interface behaviour, rate structures and conversion rules differ by platform, region and account type and change without notice; treat each channel's current admin settings and published terms as the authority, and verify on your own portal before acting.
Reviewed by
Localsbnb Editorial Team