Skip to main content

​
Migrate from Salesforce to Orbit

A Salesforce migration differs from a platform-messaging migration (Twilio, Vonage, …) in one fundamental way: the source is a system of record, not a sending pipe. When a team says “migrate off Salesforce,” they usually mean one of three different things. Pick the row that matches what you actually need before you touch a connector: The connector is identical either way — OAuth via Nango, integration_id: "salesforce". What changes is what you do after the connection is live. The sections below are ordered for a consolidation, but sections 1–4 are identical to a parallel-run setup (parallel Salesforce and Orbit for a season is fine), so they apply regardless.

​
1. What’s exported from Salesforce — know before you start

Export these from Salesforce before you change anything, while the org still has full data:
  • Contacts and Leads — a CSV per object, with the fields your campaigns reference (Email, Phone, MobilePhone, custom fields). Include OwnerId, AccountId, and your own record-type and consent fields.
  • Accounts — the company dimension. Orbit maps Accounts to the CDP accounts entity for linked audiences; export account name, tier, ARR/MRR if you segment on it.
  • Opportunities — for history and audience modeling, not for the daily workflow in Orbit.
  • Tasks / Events — Salesforce activity history. Orbit’s CRM activity logger writes new communications as Tasks into Salesforce going forward, but it does not backfill history. Export history if you need it; otherwise move forward without it.
  • Reports and list views — the segments your campaigns reference. These do not export as CSVs you can act on; you will rebuild them in Orbit as a CDP segment, or point an Orbit campaign at the Salesforce report as a live audience source (see choose the recipient list).
Keep the exported CSVs — they are the audit spine if a row doesn’t reconcile after the relink.

​
2. Connect Salesforce to Orbit (OAuth, admin-only)

The connection is the standard Nango OAuth integration. Only owner/admin roles can run it — it touches provider credentials.
The response returns an auth_url; redirect the browser to it and complete the OAuth consent. Orbit polls the org for Contact, Lead, Account, Opportunity, Ticket changes and receives real-time updates if you wire a webhook (that is optional — the poller alone works). Verify the connection landed:
Inbound syncs then populate Orbit contacts: FirstName, LastName, Email, Phone, MobilePhone, Account fields, and the salesforce:-namespaced attributes for org-specific fields. The identifier link is written on each contact as attributes.salesforce_id. Once a link exists, outbound write-back is HubSpot-only today — Salesforce is poller-only (the Provider differences table names which paths are live).

​
3. Recreate your audiences in Orbit

A Salesforce segment (a report, a saved list view, a report filter) is not a portable object — moving it means either recreating it natively on Orbit’s contact data, or pointing an Orbit campaign directly at the source while Salesforce is still live. Both are supported: Recreate audiences before you retire the SalesForce report — a campaign that points at a Salesforce report works only while the connection is live.

​
4. Mirror ongoing activity back to Salesforce (optional)

If Salesforce stays live for a period (compliance desk, finance, an org not yet decommissioned), Orbit can write each new message and call back into the contact’s engagement timeline so a Salesforce user opens a Contact and sees Orbit SMS/WhatsApp/voice/email mixed chronologically — without a poll. This runs once you enable activity logging; dispatch is fail-open per CRM activity logger (a Salesforce outage never blocks an Orbit send; failed fanouts are logged as audit + PostHog events, never retried on the critical path). The provider mapping is: Enable only when you are keeping the connection alive for a season — if you plan to cut the org in under a month, skip this step.

​
5. Rebuild the daily workflow in Orbit

This is the consolidation step — the daily engagement, messaging, and ticketing work that lived in Salesforce moves to Orbit’s own surfaces: The rebuild is gradual — leave Salesforce live while you move one workflow over at a time and harden each. The seven-step cutover runbook applies unchanged; the only provider-specific detail is which Salesforce objects step 3 (audiences) and step 6 (mirror write-back) close out.

​
6. Reconcile, then cut over

The generic seven-step cutover in Migration playbook hub works as-is; these are the Salesforce-specific verification checkpoints to hang off it:
  1. Freeze sends on Salesforce — Marketing Cloud / Account Engagement / Service Cloud outbound; whatever you have that sends. Verify your outbound queue reads empty while Orbit keeps flowing on the split traffic.
  2. Redirect webhooks — if you wired a webhook for real-time Salesforce updates into Orbit, leave it running until cutover. On Orbit, the verification is the same X-Orbit-Signature HMAC — replay a message.delivered against your receiver before you cut over.
  3. Swap API keys — cut your own integration (if any) onto an Orbit key; the OAuth connection to Salesforce itself stays until decommission.
  4. Flip sender identity — the route-by step is traffic-side, not Salesforce-side; the destination sender moves to Orbit’s numbers.
  5. Watch the first-hour parity window — delivery-rate parity on the split class before decommissioning.
  6. Hold the fallback warm — keep the Salesforce org connected (sync still running) for one full billing cycle as a compliance record if needed. The OAuth connection can be revoked separately from closing the org.
  7. Decommission — verify: the org shows no live sends, GET /api/v1/integrations shows the salesforce row revoked, and your exported CSVs reconcile row-for-row with the contacts Orbit reports imported. Then close the org.

​
7. Operate after the migration

Once cut over, the ongoing surfaces that keep a migration honest:
  • Settings → Migrations — the job history for every import run lives here, with status and rollback. Monitor, cancel, and roll back platform migrations.
  • Audit ledger — every relink, rollback, and export lands in the tenant audit log; when a contact lost its Account mapping, the ledger is the timeline that says which step introduced it.
  • Suppression and consent state — Salesforce opt-outs must exist in Orbit’s per-channel suppression before decommission, or a compliance defect follows. Opt-out lists covers how Orbit enforces it.
  • Sync health — if you left Salesforce connected as a record, GET /api/v1/integrations/{id}/status reports the per-sync last_sync timestamp, and Settings → Integrations → Salesforce → Status surfaces the same.
Consolidating off Salesforce entirely, or running both for a season? The solutions team works Salesforce offloads regularly — migrate@devotel.io with your org shape and traffic mix gets you the same dual-run plan the sections above assume.