WhatsApp Cloud API vs On-Premises API: what changed and how to plan a migration

WhatsApp Cloud API is Meta's hosted infrastructure for business messaging. The On-Premises API was a client operated on infrastructure managed by a business or its provider, and it has been retired. For a new project, Cloud API is the supported route. For a legacy installation, the task is to establish its current account state and complete a supported transition.

The date matters: Meta's sunset notice says the final on-premises client expired on 23 October 2025. By November 2025 the shutdown had already taken effect. An old server that still starts is not evidence that the retired messaging service remains usable.

At the software layer, Zena's approach is: Every Zena feature on every plan. Pick the capacity you need. Shipped software features and capacity are separate from the underlying Meta infrastructure decision.

What each API means

On-Premises API required the business or provider to operate Meta's client. That introduced responsibility for the client environment, maintenance and upgrades alongside the application's own infrastructure.

Cloud API moves operation of the WhatsApp API infrastructure to Meta. Your application sends authenticated requests to Meta and receives webhook events for incoming messages and delivery updates. You still need software to display conversations, manage work and connect to business systems.

For the wider product structure, including templates, Flows and provider roles, read WhatsApp Business API explained.

The dated transition timeline

Meta's official sunset announcement and timeline identifies these milestones:

These stages had different meanings. Ending new features did not immediately shut down existing deployments. Ending registration stopped new numbers using the old route. Expiry of the final client ended message delivery for numbers remaining on it.

For an October 2026 audit, describe on-premises as retired, not as a viable product with an approaching deadline. Ask an incumbent supplier to identify the active connection for each number. A legacy server or contract name may remain after the number itself has moved.

What migration actually changes

A migration concerns the number's API registration and the application's integration, not just where a server is hosted.

The application needs the correct Meta asset identifiers, access tokens, permissions and webhook subscriptions. Its send requests and event handling must work with Cloud API. Systems consuming those events, such as a CRM or booking service, must continue receiving the information they need.

The current number-registration documentation explicitly states that on-premises migrations require additional steps before Cloud API registration. Ordinary registration instructions should not be treated as a complete legacy migration runbook.

Editorial source gap: Meta's linked legacy migration guide returned a page shell without its instructions when checked on 18 October 2026. The checklist below covers preparation and current Cloud API requirements. The owner must obtain the account-specific transfer sequence from Meta or the incumbent provider before publishing procedural instructions.

This is especially relevant after retirement. A business recovering an inactive number may need different assistance from one whose provider already completed the transfer and only needs to replace its application integration.

Establish ownership and the actual account state

Identify the business portfolio, WhatsApp assets, phone number, current provider and administrators. Confirm that the business can authorise the change and that its records distinguish the visible phone number from the API's phone-number identifier.

Inventory templates, integrations, billing arrangements, message archives and unresolved conversations. Determine which data lives in the provider's application rather than Meta's API infrastructure. A change of API registration does not, by itself, establish that an inbox archive or CRM configuration has moved.

Ask the incumbent provider for a written transition plan identifying preserved assets, actions each party performs and expected interruption. Avoid promising a universal zero-downtime migration based on an old tutorial.

Prepare the destination integration

Meta's Cloud API getting-started guide covers app setup, test messages, access tokens and a test webhook endpoint. Use controlled test records to verify the integration before scheduling changes to the business number.

The application should authenticate requests securely, receive incoming messages and track delivery status. Review the production token and asset permissions separately from the temporary credentials used during initial testing.

Map old application assumptions explicitly. Check recipient identity, supported message formats, media handling, template selection and the way failures reach staff. If a message triggers a business action, make sure repeated events cannot create duplicate bookings or orders.

Execute the agreed transfer and registration sequence

Follow the validated migration procedure for the current number and account. Meta's present registration interface uses a POST request to PHONE_NUMBER_ID/register, with the required messaging product and two-step verification PIN. This is a registration operation, not a substitute for the migration prerequisites.

Coordinate changes to the application's sending route and webhook configuration. Control queued work so old and new components do not independently send the same customer update. Record who decides whether the transition can proceed if validation fails.

A rollback plan cannot assume that the retired on-premises service is available. Agree a recovery path through the supported platform and provider, together with a way for staff to handle urgent customer requests during interruption.

Validate business continuity

Test an incoming enquiry, an allowed reply, a template message and the associated delivery events. Confirm that staff can identify the conversation and that the correct business record is updated.

Also test failures. A rejected message must not be shown as delivered. An unavailable booking system must not produce a confirmation. Reconcile pending work before stopping obsolete jobs or retiring infrastructure, and retain records according to the business's requirements.

What changes about cost

Cloud API removes the need to run the retired WhatsApp client infrastructure. That can reduce hosting and maintenance work, but it does not eliminate the cost of the business application, integrations, monitoring or support.

Separate infrastructure costs from Meta's messaging charges and your provider's commercial model. Meta's current pricing page reflects per-message billing and the October 2026 changes. Moving to Cloud API is not a promise that message charges disappear.

Zena adds zero markup to Meta's message fees on every plan. Software capacity and any connected services remain distinct budgeting considerations. For current message-fee detail, use the October 2026 pricing guide.

Assess total operating cost against your own deployment. Generic infrastructure savings claimed by another business are not a reliable forecast for a small, heavily integrated or already provider-managed installation.

Reliability moves, but responsibility remains

Meta operates the Cloud API infrastructure, while your business or provider remains responsible for its application. A healthy Meta API does not guarantee that your webhook endpoint, database or order system is working.

Monitor both sides. Track API failures, webhook processing, queue delays and unresolved business actions. Give staff a useful explanation when an integration cannot complete a request, and provide a route for manual handling.

Data storage also needs a separate review. Meta documents local-storage options for Cloud API, but an API storage setting does not automatically determine where your provider stores conversation history, logs or backups. A UAE business with residency requirements should review the complete data path and the actual configuration.

Do not turn Meta's infrastructure performance statements into a Zena service-level guarantee. Agree support responsibilities and any contractual commitments with the relevant supplier.

Scaling requires more than a faster API

Meta's throughput documentation lists 80 messages per second by default for Cloud API numbers, with eligible numbers able to reach 1,000 messages per second. Coexistence numbers have their own fixed 20 messages-per-second limit.

Those figures describe throughput, including inbound and outbound messages. They are separate from portfolio messaging limits, template quality controls and the capacity of your own application.

Prepare the receiving systems as well as the sender. A campaign can generate delivery events, replies and staff tasks. A faster send rate is not useful if the business cannot process the resulting work.

Measure queue behaviour and successful business actions during controlled load checks. Request higher throughput only as part of a workload plan that respects current account eligibility and the team's ability to respond.

Plan for the next Platform transition too

Retiring On-Premises API did not end changes to the Platform. Meta's Marketing Messages API overview announces the end of marketing-message support on Cloud API on 13 October 2027, with an earlier restriction for newly created Messaging accounts from 13 April 2027.

This concerns marketing-message routing. Cloud API continues supporting service, utility and authentication messages. A migration plan should therefore establish a supported foundation while checking the provider's route for future marketing sends.

The Marketing Messages API guide explains that separate change. Do not confuse it with the completed retirement of the old on-premises client.

Start with the business process

For a new implementation, define the customer work you want to support and select software that can complete it on the supported Platform. For a legacy installation, establish account ownership and current registration before changing anything.

Zena's planner helps identify useful automation possibilities for your business. Those possibilities provide a starting point for onboarding and technical planning, with the connection and workflow requirements assessed together.

See what your business can automate