How to migrate from CM.com to Vonage

CM.com is a conversational commerce and customer engagement platform that sends business messaging across SMS, RCS, WhatsApp and other channels, plus voice, email and payments. Vonage is a communications-API platform (part of Ericsson) covering SMS, voice, video and messaging. On the messaging.dev Score, CM.com rates 58/100 and Vonage 89/100; this guide walks through what actually changes when you move your sending code from one to the other.

What changes at a glance

Channels you keep: SMS, RCS, WhatsApp, Viber, Facebook Messenger and voice are available on both.

Channels you gain: MMS. CM.com does not list MMS; Vonage does.

Channels you lose: Telegram, Apple Messages for Business and email are all on CM.com but not on Vonage. If any of your traffic uses those, you’ll need to keep CM.com or another provider for them.

Compliance: Both hold GDPR and ISO 27001. Vonage additionally lists SOC 2 and HIPAA, so you gain those certifications by moving.

Data residency: CM.com hosts in the EU only, with no US servers and no region choice. Vonage offers both EU and US servers, plus APAC and Australia, and lets you choose your data-residency region.

Pricing and credit: Both bill pay-as-you-go per message with volume discounts. CM.com does not publish flat rates (pricing is per destination country, selected on its pricing page); Vonage publishes a starting price of roughly $0.0072 per US SMS segment plus carrier fees. Vonage also gives €2 free trial credit; CM.com offers no free developer credit.

SDKs and tooling: Both cover Node.js, Python, PHP and Java. CM.com adds .NET; Vonage adds C#, Ruby and Kotlin. Both have high-quality docs and a sandbox test environment. One protocol note: CM.com offers REST and SMPP, whereas Vonage is REST-only, so an SMPP binding does not carry over.

How the request format differs

CM.com quickstart:

curl -X POST https://gw.messaging.cm.com/v1.0/message \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  -H 'X-CM-PRODUCTTOKEN: <YOUR_PRODUCT_TOKEN>' \
  --data-raw '{
    "messages": {
      "msg": [{
        "from": "Sender",
        "to": [{"number": "00447911123456"}],
        "body": {"type": "auto", "content": "My first CM.com message"},
        "reference": "my_reference_123"
      }]
    }
  }'

Vonage quickstart:

curl -X POST 'https://rest.nexmo.com/sms/json' \
  -d 'api_key=YOUR_API_KEY' \
  -d 'api_secret=YOUR_API_SECRET' \
  -d 'from=Vonage' \
  -d 'to=15551234567' \
  -d 'text=Hello from Vonage'

Three things change:

• Endpoint. You POST to https://gw.messaging.cm.com/v1.0/message on CM.com. On Vonage you POST to https://rest.nexmo.com/sms/json (legacy SMS API) or https://api.nexmo.com/v1/messages (Messages API).
• Authentication. CM.com passes a single product token in the X-CM-PRODUCTTOKEN header. Vonage’s SMS API takes an api_key + api_secret pair sent as request parameters; the newer Messages API uses JWT auth instead.
• Payload shape. CM.com sends a nested JSON document: recipients live in messages.msg[].to[].number, the sender in from, and the text in body.content. Vonage’s SMS API is flat, form-encoded key/value pairs. So to[].number maps to to, from stays from, and body.content maps to text; you also drop the messages.msg[] wrapper. Watch the number format too: CM.com’s example uses a 00-prefixed international number, Vonage’s uses plain digits.

Migration checklist

1. Create a Vonage account and generate your API key + secret (or an application + JWT for the Messages API). New accounts include €2 trial credit.
2. Map the request fields: to[].number to to, from to from, body.content to text, and remove the nested messages.msg[] structure.
3. Re-point your sending code to the new base URL and switch from the header token to key/secret (or JWT).
4. Re-test in Vonage’s sandbox before sending any live traffic.
5. Update your delivery-receipt/webhook handlers to Vonage’s callback format.
6. Run both providers in parallel and compare delivery and cost.
7. Cut over once the numbers look right.

Watch out for

• Lost channels: Telegram, Apple Messages for Business and email are not on Vonage; keep CM.com or another provider if you rely on them.
• No SMPP: Vonage is REST-only, so an existing SMPP integration must be rewritten.
• Two APIs, two auth models: the legacy SMS API (key/secret) and the Messages API (JWT) behave differently; pick one deliberately.
• Number formatting: align recipient formatting with Vonage’s expectations to avoid silent delivery failures.

See the full how to start with Vonage guide, or the CM.com vs Vonage comparison for the complete side-by-side.