Migrating from the WhatsApp Business app to the API without losing chat history

The question almost always arrives the same way: "we have several locations, the app isn't enough anymore, but we don't want to lose our chat history with customers". It's the right question and it deserves an honest answer before anyone talks about quotes.

Short answer: the app's chat history does not transfer to the API. That's the part almost nobody tells you straight. The long answer is that it can be preserved, just not the way you're picturing, and that the number does carry over, which is what actually matters.

What carries over and what doesn't

The number carries over. Meta documents the process to migrate an existing WhatsApp number to a business account. Your customers keep messaging the same contact they already have saved. This is the critical part and what makes the migration worth doing.

Conversation history does not transfer. The API isn't an app with an inbox: it's an interface that delivers and receives messages. There's no chat archive that travels. From the migration onward, history lives wherever you store it, in the CRM or the agent inbox you connect.

The app's tools don't carry over. Quick replies, labels and the catalog you configured in the app don't cross. They get rebuilt on the other side, usually better, because a CRM handles them with more judgment.

That's why the migration is planned in advance, not improvised.

How history is actually preserved

Three things, in this order:

1. Export chats from the app before migrating. The app itself allows exporting conversation by conversation. It's manual and tedious, and for a business with thousands of chats exporting everything isn't realistic. Our recommendation: export the active customers and the open cases, not the full historical archive.
2. Load contacts into the CRM before the cutover. What you operationally need isn't the text of every conversation from two years ago, it's knowing who each customer is and where things stand. That migrates as contacts with notes, not as transcripts.
3. Decide from day one where new history lives. This is the mindset shift: in the app, history sat on a phone; with the API it lives in a system your team logs into. It's an upgrade, even if the cutover is uncomfortable.

Worth saying plainly: if what's holding you back is losing old transcripts, the real cost of losing them is almost always far lower than the cost of running several locations on an app that was never designed for it.

The multi-location case

There's an architecture decision here worth making deliberately, because changing it later is expensive.

One number for the whole business. Customers message a single contact and routing decides which location handles it. Upside: one brand, one base, one number you promote. This is what we recommend in most cases.

One number per location. Each site keeps its own. Upside: continuity for customers already messaging their location, and local autonomy. Cost: multiple accounts, multiple verifications, duplicated templates and fragmented reporting.

The hybrid. A central number for new acquisition, with location numbers migrated as additional numbers on the same business account. More setup work, and usually the right call when locations already have loyal customer bases.

What we don't recommend is leaving some locations on the app and others on the API. The operation becomes impossible to measure and nobody knows where to look for a conversation.

The prerequisites to have ready

Onboarding onto the official platform isn't scanning a QR code. What you need:

• A Meta Business account in your business's name. Not the provider's. We insist on this in official API vs unofficial solutions for a reason: it's the difference between owning your channel and renting it.
• Business verification. Tax and address documentation.
• An approved display name. Meta reviews that it matches the real business.
• The number removed from the app at cutover. A number can't be active on both sides.
• Approved templates for anything you send outside the 24-hour window. They're prepared before the cutover, not after, and they take time. The template approval guide explains why.

The account structure is documented in WhatsApp Business accounts.

Cutover day

• Do it during your lowest-volume window, not a Monday at 10am.
• Have templates already approved. If the cutover happens and you have no templates, you can't start conversations.
• Start at low volume. Messaging limits begin at the entry tier and rise with good behavior. Sending everything on day one is how you start with a poor rating.
• Brief your team beforehand. The tool change confuses people more than the technical change does.

When not to migrate

If you have a single location, one or two agents, and no need to integrate with your systems, the free app serves you and migrating is spending for no reason. The real threshold isn't business size: it's when you need multiple simultaneous agents, integration with a system, or automation. We develop this in is it worth automating WhatsApp and in how much the API costs.

We handle these migrations as an authorized Meta Tech Provider, with the account in the client's name. If you want us to review your case, especially if it's several locations with separate bases, that's what our WhatsApp automation service covers.