It is 18 July. You signed up for the new platform on Tuesday, for reasons that have been accumulating since March. Right now there are nine guests inside your properties, and four have an open thread with you: one waiting on a plumber, one who agreed a 14:00 arrival on Saturday in a message that exists only in the old tool, one asking about the beach bus, one who has said nothing since Monday.
Somewhere in the next three weeks you have to move all of that onto the new system without any of those four noticing.
Tool comparisons end at the purchase, which is the moment the actual risk starts. The migration is where guests get dropped, not dramatically, but in the way that produces a four-star review saying "communication was a bit hit and miss", which is worse than a complaint because you never find out what happened.
This article covers what is genuinely at stake, a sequence that does not drop anyone, the two failures that cause most of the damage, what to test first, and what to accept losing before you begin rather than after.
What Is Actually at Stake
Most migration plans list two things (messages and contacts) and miss the rest. The full inventory is longer, and the items move with very different amounts of difficulty.
| What you have | Moves cleanly | Usually does not | What to do |
|---|---|---|---|
| Guests currently in a property | No | The live thread and its context | Leave them on the old tool until they check out |
| Booked guests with an existing thread | Partly | Promises made in that thread | Re-state the promise in the new channel before the old one goes quiet |
| The phone number itself | Rarely, and never instantly | In-flight conversations attached to it | Plan it as its own project, at the quietest moment you have |
| Accumulated answers and house knowledge | As a file | Its accuracy | Re-verify anything with a code, a password or a person's name in it |
| Approved message templates | No | The approval itself | Assume re-submission and re-approval time |
| Escalation routing and who watches what | No | The habit your team has built | Write it down again, explicitly, for the new tool |
Read the middle column. What breaks in a migration is not the data (data is the easy part); it is the context, the accuracy and the promises. A thread that says "we agreed you can drop bags at 12:00" is a commitment, and it lives in a system you are about to stop reading. The most underrated item is the accumulated knowledge: two seasons of answers to questions you did not anticipate, which is the difference between a tool that works and one installed last week. It is a real asset, and the one most likely to carry an error across.
Run in Parallel, Not as a Cutover
A cutover is a moment when the old system stops and the new one starts. It is the wrong shape for this, because the failure mode of a cutover is silence, and silence is the one outcome a guest actually punishes.
Parallel running gives you the opposite failure mode. With both systems watching, the worst case is a guest getting two answers to one question. A duplicate reply reads as keen; six hours of nothing reads as abandonment, and gets written up that way.
The cost is real: for some weeks you pay for both and have two places to look. That is the price of the migration and belongs in the budget next to the subscription. A plan that avoids it by cutting over on a Sunday night is not cheaper: it has moved the cost onto whichever guest messages first on Monday.
The Sequence, Property by Property
Move in waves small enough that a failure affects one property and one guest, not the portfolio.
- Pick one property with no stay in progress and no arrival for 48 hours. Load it completely (access, WiFi, appliances, rules, recommendations) and test it before it is live to anyone.
- Point only future bookings at the new setup. Choose a date; arrivals from that date get the new channel, and everyone booked in before it stays where they are.
- Add properties in waves, simplest first. The studio with a keypad goes early. The apartment with the neighbour who lets guests in, the lift fob and the parking barrier goes last, once you trust the setup.
- Take in-flight stays last, or not at all. A stay in progress is at most a couple of weeks long, and letting it finish where it started costs nothing while removing the highest-risk category from the migration.
- Keep the old channel monitored well past the last stay that used it. Guests message after checkout: a charger left in a drawer, an invoice, a question prompted by the review request. Two weeks past the last old-channel departure feels excessive and is roughly right.
- Change the printed material last. The welcome card, the sign inside the door, the number in your listing and in the confirmation emails already sent. Until those are updated, the old number is still a live entrance to your operation.
Keep a one-page map of which property is on which system and who watches which inbox, where your co-host or cleaner can see it. During a parallel run, "who is answering this?" needs an answer that does not require you.
The Number Is Where Most Migrations Break
Here is the failure that does the most damage, because it happens silently and to guests who are already mid-conversation.
A WhatsApp number is tied to an account with a specific provider. Moving it to a different provider means deregistering it on one side and registering it on the other, and the exact process, the waiting periods and the verification requirements change: check the current documentation before you plan dates around it. What is consistent is the shape of the risk: there is a window during the move when the number is not reliably reachable, and the conversations that were open on the old side do not arrive on the new one. A guest who sent "the code isn't working" into that window gets no answer and no error.
There are two workable responses.
Move the number, in the quietest window you have. Do it when the count of in-flight conversations is lowest (typically a weekday morning after departures and before arrivals) and tell anyone with a live thread, in advance, that you will follow up from the same number shortly. Accept that anything sent during the window may be lost.
Or start the new system on a new number and retire the old one slowly. This removes the outage entirely and costs a longer parallel period plus the work of updating every place the old number is printed. For most small portfolios it is the safer trade.
Either way, treat template approvals and sending reputation as things that start over rather than travel: if outbound messages go through an approval process, budget re-approval time before the first arrival depends on them. The account and number mechanics are covered in setting up WhatsApp Business for a vacation rental, worth re-reading before a move.
The Knowledge Base Nobody Re-Checks
The second common failure is quieter and lasts longer. You export your accumulated answers from the old tool, import the file into the new one, confirm that it loaded, and move on. Eleven weeks later a guest is standing outside at 23:40 entering a lockbox code that was changed in March.
The export is a snapshot of everything, including entries that stopped being true and were only ever corrected verbally. The lockbox code changed after a guest shared it. The WiFi password changed with the router. The cleaner whose number sits in the emergency answer left in May. None of those corrections reached the knowledge base, because in daily use you answered the guest correctly and never went back.
A migration is the one moment you will ever re-read that material, so use it. Do not import wholesale. Triage instead:
- Anything containing a code, a password or a key location gets verified against the physical property, by someone standing in it, not against the old system, which is where the error is.
- Anything naming a person or a phone number gets checked against who currently does that job.
- Anything with a date or a season in it (pool opening, heating schedule, bin day, the market that runs on Saturdays in summer) gets re-read for the current year.
- Everything else can come across as it is.
That is a couple of hours per property, once. The alternative is a wrong access code surviving the migration and becoming a lockout at midnight: a one-star review with a factual complaint attached.
What to Test Before a Real Guest Sees It
Before any guest is pointed at the new setup, run the checks a real stay would run. Have a second person do it, ideally the co-host who will be answering, because you will unconsciously phrase questions the way the system already knows them.
- Message from a number with no reservation attached and confirm a stranger gets nothing useful, then from a number attached to a genuine upcoming booking and confirm it is recognised.
- Ask the three questions that actually get asked: the door code, the WiFi, the parking. Check the answers against the property.
- Ask one of them in a second language, and read what comes back.
- Trigger an escalation and confirm it arrives on a device that is not the one you are testing from.
- Check that tomorrow's arrivals are visible, and that a booking made an hour ago has appeared, so you know the real lag of the calendar sync rather than the advertised one.
- Send a message at 02:00, or set the clock forward, and confirm that the out-of-hours behaviour is what you assumed it was.
If the tool has a simulator, use it for the first pass, then do a live test with your own phone anyway: a simulator tells you the assistant answers correctly, only a real message tells you it arrives.
Decide What You Are Willing to Lose, and When to Do This at All
Some things do not move, and the time to decide how you feel about that is before the migration rather than during it. Message history is the main one: threads stay in the system that holds them, and an export is a file, not a searchable inbox. Template approval history, opt-in records and whatever tenure your number built up are in the same category.
Make the decision explicitly. Most small operations land on: keep an export of the last twelve months for disputes, accept that searching it will be worse, let the rest go. Treat the export properly: it is a file of guests' personal data on someone's laptop, so keep it somewhere controlled and delete it when the migration is done.
On timing, the honest answer is unwelcome: there is no good time to do this mid-season. Every week has guests in it, and the weeks that look quiet are the ones where you are least staffed. If you have a shoulder season, that is the answer: the gap between the last October departure and the first March arrival exists for work like this, and a migration done then costs a fraction of the same one done in July.
If you cannot wait, because the current tool is actively failing rather than merely annoying you, then you are responding to a fire and should act like it: one property, the lowest-occupancy week you can find, never the week before a public holiday, and a fortnight of margin before your next peak. Choosing the tool itself is a separate decision, and how to choose a guest communication platform plus the buyer's guide to WhatsApp automation tools are the places to make it, ideally before the fire, not during.
Where This Breaks
Parallel running assumes you can staff two inboxes. If there is one of you and no cover, "run both for six weeks" is a plan you will abandon in week two, at which point you have a cutover with extra steps. A solo host should shorten the parallel window and shrink the waves rather than pretend to a capacity that does not exist.
Property-by-property assumes your properties are independent. If eight apartments share a building, a lockbox convention and one cleaner, the smallest safe unit is the building, not the flat. Move them together or you will maintain two versions of the same access instructions.
A good plan reduces the loss; it does not eliminate it. You will lose some history, some context and probably one conversation. The sequence exists so that the one you lose is a question about bin day rather than a guest locked out at midnight.
Vendor migration support is worth what you can get in writing. Any vendor will call the move straightforward. Ask four questions (does my number move, do my threads move, do my templates need re-approval, what happens to a conversation in flight at the moment of the switch) and treat a vague answer as a no. That applies to Welco as much as to anyone else.
And about Welco specifically. Reservations sync by iCal from Airbnb, Booking.com, VRBO and Hostaway with no PMS required, which removes one painful piece of a migration, and a simulator lets you test before a guest sees anything. But Welco does not import another tool's message history, and the assistant knows only what you load into it. Answers are saved once you give them, so knowledge accumulates from the point you start rather than from the point your old tool started, and the first weeks after a move carry the most escalations. Staff for that rather than expecting day-one parity, and be sceptical of any vendor, including this one, that describes a mid-season migration as quick.
The Operational Picture
A migration done well is unremarkable from the guest side, which is the objective: nobody notices, nobody waits, and the number on the door still works. Move in parallel, in waves, in-flight stays last, and spend the migration re-verifying the knowledge rather than trusting the export. If you are still deciding which channels to carry across at all, WhatsApp, SMS and email compared is the prior question, and the wider view of guest experience automation covers what the new tool is supposed to be doing once it is in place.
Welco is a WhatsApp AI assistant for vacation rental hosts, built to sit on your existing reservation calendar rather than on a PMS migration. If you are weighing a move, a demo is the place to ask the awkward questions: what moves, what does not, and what the first three weeks actually look like.