Moving from a BSP to direct Cloud API is an account-access and workflow project before it is an API change. First identify who owns the number and which Meta account model applies. Then plan messaging assets, routing, history, billing, and recovery as separate workstreams.
Do not begin by deleting the number or cancelling the provider. Those actions can remove the access and evidence needed to complete the transition safely.
Check the account model before following a migration guide
Last verified: October 2026. Meta's current programmatic migration page explicitly says phone-number migration is unsupported on the new WhatsApp account model. Disconnecting a number does not make it available to another account. The documented alternatives include sharing the owning WhatsApp account; moving within the same business portfolio uses a distinct linking process. Product behavior can change.
The account-model documentation separates a WhatsApp account holding the number from Messaging accounts holding templates, billing, and webhook subscriptions. It also explains compatibility during the rollout. Inspect the actual assets and supported flow in your business account instead of treating every old WABA migration tutorial as current.
If an account still follows a legacy path, confirm the supported route with Meta and the current provider before performing irreversible operations. This article deliberately does not supply a universal deregister-and-register command sequence because the same sequence is not valid for every account model.
Establish ownership and access
Create an inventory with the business portfolio, number, WhatsApp account, Messaging accounts, app, administrator access, provider relationships, and payment methods. Record IDs as returned by your account, including how the current integration uses them.
Ask the business to confirm administrative access directly. A screenshot of a number in a provider dashboard is insufficient. The team needs to know which assets are business-controlled, which are shared, and which depend on the provider's contract.
Resolve disputed ownership before implementation. If the provider controls an asset the business expected to own, the next step is a documented access resolution, not an engineer attempting to force the number through another onboarding flow.
For choosing the target operating arrangement, see Cloud API vs BSP.
List everything the provider currently does
An exit can remove more than API transport. Inventory the inbox, agent assignments, chatbot logic, CRM callbacks, scheduled sends, template management, analytics, opt-outs, and support processes.
For each function, name its replacement and acceptance test. An outbound send test will not reveal that staff can no longer search an open complaint. A connected CRM will not reveal that an old campaign remains scheduled in the provider's automation system.
Export only data the business is entitled to retain and process, through the provider's supported facilities. Confirm whether exports contain message identifiers, timestamps, attachments, assignment history, consent records, and delivery states. No general history-export guarantee was verified, so inspect a sample before making it a cutover dependency.
Keep contact suppression and unfinished customer work particularly visible. Losing either can produce unwanted messages or unanswered enquiries immediately after the move.
Treat templates as a separate dependency
Build a template inventory with account, name, language, category, approval state, purpose, and variables expected by application code. Link each template to the business events that use it.
Templates and billing belong to Messaging accounts in the new model. Do not assume that access to the number automatically makes every previous template available through the target account. Check the supported reuse or copying route, permissions, and current approval state for your actual configuration.
Before cutover, send every essential template from the target setup to consenting test recipients. Confirm parameter order, language, links, media, and delivery. If a template needs review, treat that as an unresolved release dependency rather than promising that approvals transfer instantly.
Maintain a controlled fallback for critical communications through another authorized channel. The template and window guide explains why a delayed notification cannot always become a free-form message.
Prepare routing before adding another integration
Meta's current readiness guide warns that assigning another partner can create initial Conversation Routing configuration when none exists. Normal inbound events may then go to a selected primary responder instead of every connected integration, and a non-owner's replies may fail.
Inspect routing in Meta Business Suite before making the assignment. Identify every direct and provider integration using the account, including automations that staff may have forgotten. Confirm which integration should receive new enquiries, which needs standby visibility, and how escalation works.
Test an existing conversation as well as a new one. Routing changes can apply gradually because existing ownership is not necessarily transferred by saving a configuration. A successful fresh test therefore does not prove that all open support cases reached the new inbox.
Do not run two independent reply bots against the same number without a deliberate ownership model. At cutover, one system should have clear authority to respond to a given interaction.
Build and test the direct workflow first
Implement the receiving endpoint, signature verification, durable event store, deduplication, queued processing, and delivery-state tracking before changing customer traffic. Rebuild the required human inbox or connect a suitable replacement.
Use new credentials appropriate to the target app and assets. Do not copy provider credentials into your application unless the supported arrangement explicitly grants that use. Keep secrets server-side and document how access will be revoked after the move.
The Cloud API implementation guide covers the test-to-production sequence. Include an ambiguous outbound timeout in testing: an internal outbox does not by itself prevent duplicate delivery when the remote send result is unknown.
Run a controlled cutover
Use a runbook with a named technical owner and an operations owner. Pause overlapping scheduled automation, reconcile pending messages, confirm target billing, and record open customer cases before changing routing or access.
Move the supported configuration through the agreed account-specific process. Verify inbound events, human replies, a required template, CRM updates, delivery statuses, and opt-out handling. Observe both old and new systems long enough to find work arriving at the wrong destination.
Define rollback by reversible actions and evidence. Returning a routing setting is different from recreating deleted account assets. Do not promise zero downtime or a guaranteed rollback for a number operation you have not rehearsed and confirmed as supported.
Close the old arrangement deliberately
After the target workflow is stable, reconcile remaining invoices, exports, customer cases, retention obligations, and scheduled work. Revoke obsolete access using the supported process and confirm that required business assets remain available.
Keep an audit of what moved, what remained, and what was deleted. Cancellation is complete when the business can operate the new workflow and explain the fate of its data, not merely when the provider subscription disappears.
Apex's WhatsApp integration team can review the account inventory and cutover plan before the production change.