This is the provider-agnostic sequence for moving a messaging programme to Furcata. It assumes you are leaving a platform that offers contacts, campaigns and long-code or toll-free messaging — the pattern is the same for most of them.
Prerequisites
- Administrator access to your current provider.
- A Furcata account you can administer.
- A list of the workflows you must reproduce, ranked by how much you rely on them.
- Enough time to run both systems in parallel.
Before you export anything, write down what you actually use. The list is usually shorter than people expect, and it tells you what to rebuild first.
- Which numbers you send from, and which receive replies.
- Which campaigns or automations run, and how often.
- Which integrations feed contacts or trigger messages.
- Which reports you look at, and what you use them for.
- Where your consent records live, and what they contain.
Export contacts, message history and consent records from the current provider. Do this before you change anything, and keep the export.
Consent records are the part people forget. A contact without evidence of consent is a liability on the new platform as much as the old one, so bring the evidence with the number.
Create the account, the messaging service and the number you will send from. Acquire the number before you need it — availability in a specific area code is not guaranteed, and the number is the thing your audience will recognise.
Contacts are identified by phone number. Import them in international format, and expect some records to be skipped because the number is not usable.
{
"phone": "+15555550100",
"firstName": "Alex",
"lastName": "Morgan",
"language": "en",
"unsubscribed": false
}Import in batches and check the results as you go. A skipped record has a reason attached, which tells you whether the problem is the format or the data.
Carry opt-out state across. Anyone who unsubscribed with the old provider must arrive unsubscribed, or you will message people who have already told you to stop.
If you are sending application-to-person messages in the United States or Canada, register your brand and campaign on the new platform. A registration made by your previous provider does not carry across, and sending before it is approved will be filtered.
This step takes time and sits on the critical path, so start it as early as you can. See the sender registration page for what you will need.
Rebuild in order of importance, not in order of ease. Start with the workflow whose failure would be noticed soonest.
- Recreate templates and saved replies.
- Rebuild automations and scheduled campaigns.
- Reconnect integrations — a store connection, an automation platform, or your own system calling the API.
- Subscribe to webhooks so you have delivery outcomes in the new platform, not only in the old one.
Use an idempotency key on every send you build. It costs nothing and it prevents the classic migration bug: a retry during a period of change producing a duplicate message.
Send each rebuilt workflow to a small set of internal numbers before it touches a customer. Read the messages on a phone rather than in a dashboard.
Keep both systems able to send while you build confidence. Send the new platform's traffic to a subset of your audience first, then widen it.
- Move the remaining traffic to the new platform.
- Keep the old provider's inbound path open long enough to catch replies to messages it already sent.
- Watch delivery and failure reports closely for the first few days.
- Only then cancel the old account, and keep the export for your records.
Porting is a separate project
If you need to keep the exact number you have today, that is a number port, not a migration. It has its own timeline, it depends on the losing and gaining carriers, and it should be started well before the cutover. Do not plan a migration assuming the number will follow.
- Cancelling the old provider before the new one has sent successfully.
- Importing contacts without their opt-out state.
- Starting the sender registration late and discovering it is the long pole.
- Assuming history, templates and automations will move.
- Testing in a dashboard rather than on a phone.
Next: moving your contacts
The contact import is where most migrations either go smoothly or go wrong. It has its own page.
Moving your contacts