Migration guide

How to migrate from LINK Mobility to Vonage

A developer-focused guide to moving SMS and messaging traffic from LINK Mobility to Vonage, covering channel and compliance differences, request-format changes, and a step-by-step migration checklist.

LINK Mobility is a European communications-platform-as-a-service (CPaaS) provider offering SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, Telegram, voice, and email over REST, SMPP, and SOAP APIs. Vonage is a communications-APIs platform (part of Ericsson) covering SMS, voice, video, and messaging over a REST API. On the messaging.dev Score, LINK Mobility rates 36/100 and Vonage 89/100; this guide covers what actually changes when you move.

Channels you keep, gain, and lose

Both providers cover the same core set: SMS, MMS, RCS, WhatsApp, Viber, Facebook Messenger, and voice. Neither supports Apple Messages for Business. Moving to Vonage means you lose two channels that LINK Mobility offers: Telegram and email. There are no new channels to gain. If your current stack sends on Telegram or email, plan a separate provider for those before you cut over.

Compliance, residency, and pricing

Both hold GDPR and ISO 27001. Vonage additionally holds SOC 2 and HIPAA. On data residency, LINK Mobility runs EU servers only with no region choice, while Vonage offers EU and US servers plus APAC and Australia, with an explicit data-residency choice. The pricing model also differs in transparency: LINK Mobility uses volume-based enterprise pricing negotiated through sales, with per-message rates not published; Vonage publishes pay-as-you-go rates (approximately $0.0072 per US SMS segment, plus carrier fees) with volume discounts. Vonage adds a €2 free trial credit and self-service onboarding; LINK Mobility offers neither and may require a short activation call.

Tooling and docs

LINK Mobility ships no official SDKs and has no sandbox, and its docs are rated medium. Vonage ships SDKs for Node.js, Python, PHP, Java, C#, Ruby, and Kotlin, provides a sandbox test environment, and its docs are rated high. One trade-off runs the other way: LINK Mobility exposes REST, SMPP, and SOAP, whereas Vonage is REST-only, so any SMPP or SOAP integration must be rebuilt on REST.

How the request format differs

Source (LINK Mobility):

curl -X POST https://n-eu.linkmobility.io/sms/send \
  -u "USERNAME:PASSWORD" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "LINK",
    "destination": "+4799999999",
    "userData": "Hello world",
    "platformId": "0",
    "platformPartnerId": "0",
    "useDeliveryReport": false
  }'

Target (Vonage):

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'

The base URL changes from LINK Mobility’s regional host https://n-eu.linkmobility.io/sms/send to https://rest.nexmo.com/sms/json (legacy SMS API) or https://api.nexmo.com/v1/messages (Messages API). Authentication changes too: LINK Mobility uses HTTP Basic Authentication (the -u username:password Authorization header); Vonage uses an API Key plus API Secret passed as request parameters on the SMS API, or JWT auth on the Messages API. The payload structure shifts from a JSON body to form-encoded parameters, and the field names map as follows: source becomes from, destination becomes to, and userData becomes text. LINK-specific fields such as platformId, platformPartnerId, and useDeliveryReport have no direct Vonage equivalent.

Migration checklist

  1. Create a Vonage account and generate your API Key and API Secret, or set up a JWT application for the Messages API. See how to start with Vonage for the walkthrough.
  2. Map the request fields: endpoint, auth mechanism, and payload (source to from, destination to to, userData to text).
  3. Re-point your sending code to the new base URL and switch from a JSON body to form-encoded parameters (or adopt the Messages API JSON schema).
  4. Re-test in Vonage’s sandbox, which it provides, before sending any live traffic.
  5. Update delivery-report webhooks and callbacks; LINK’s useDeliveryReport flag has no direct equivalent, so configure DLR callbacks on the Vonage side.
  6. Run both providers in parallel, comparing delivery and error rates on real numbers.
  7. Cut over and decommission the LINK Mobility path.

Watch out for

  • You lose Telegram and email as channels; if you use them today, keep or add a provider that covers them.
  • You lose SMPP and SOAP access; Vonage is REST-only, so protocol-level integrations need rework.
  • No certification regresses in this move: Vonage adds SOC 2 and HIPAA on top of the shared GDPR and ISO 27001, so compliance coverage widens rather than narrows.

For a full side-by-side, see the LINK Mobility vs Vonage comparison.