Salesforce Open CTI retirement and migration planning

Salesforce schedules Open CTI retirement for February 28, 2028, according to its current retirement guidance, checked October 9, 2026. If your Salesforce calling experience depends on Open CTI, plan a supported replacement before that date.

The first decision is whether the integration you use is affected. A telephony vendor's name, a recently updated package, or an embedded softphone does not establish its underlying integration technology. Ask the vendor to identify the installed product, version, and dependency on the Open CTI JavaScript API.

Retirement concerns that Salesforce integration layer and its dependent features. Do not assume it means the carrier's entire phone service will stop. Establish separately what happens to dialing, routing, screen pops, logging, recordings, and access outside Salesforce.

Inventory the workflow before comparing products

Record the package and version, assigned users, call center definitions, softphone layouts, custom components, and any code using Open CTI. Ask the supplier about dependencies hidden inside its managed package.

Then inventory the business behavior:

• Inbound numbers, queues, operating hours, overflow, and after-hours coverage
• Outbound dialing, caller ID, country coverage, and callback handling
• Transfers, conferences, voicemail, supervisor features, and mobile use
• Candidate and client matching, including ambiguous phone-number matches
• Dispositions, notes, recording links, reports, and downstream automation
• SMS or other channels supplied through the current vendor

For each item, record who uses it, its current behavior, and the consequence of losing it. “Must retain candidate callback ownership” is a testable requirement. “Keep everything the same” is not a workable migration specification.

Compare supported paths and require dependency evidence

Salesforce's migration-path guidance currently lists four Voice offerings. Some documentation still uses earlier Salesforce Voice or Service Cloud Voice names, so reconcile product names with the actual SKU and package in the proposal.

These are candidates for assessment, not blanket recommendations. Confirm licenses, editions, usage charges, number availability, recording storage, data location, support arrangements, and the precise features available in your deployment.

A generic “third-party CTI adapter” is not a retirement-safe category. Require written confirmation that the proposed replacement does not depend on the retiring Open CTI API, plus current documentation and an end-to-end demonstration. A marketplace listing or a vendor's general Salesforce partnership does not answer that question.

Custom development also needs a supported integration architecture. Adding AI to a softphone does not remove an underlying Open CTI dependency. Use Salesforce's migration and developer documentation to establish the supported extension points before committing to a build.

Test a staffing workflow that crosses several boundaries

Example: a staffing coordinator receives an after-hours call from a worker, transfers it to the on-call team, and records a follow-up against an assignment.

The pilot should prove that the published number reaches the correct queue; the worker's number produces the right record or a safe choice when several records match; the transfer preserves enough context; and the final disposition and callback owner remain available to the next coordinator.

Now make it fail. Disconnect the browser, interrupt CRM writes, transfer twice, leave voicemail, and repeat a provider callback. Confirm that failures become visible and that recovery does not create duplicate activities or attach a recording to the wrong person. Use synthetic or appropriately approved test data.

This exposes more than a successful click-to-dial demonstration. Routing may belong to the telephony platform, record matching to Salesforce configuration or code, and recording access to a separate provider permission model. Name an owner for each boundary.

Design the call record and reporting transition

Do not define success solely as “a Task was created.” Salesforce's migration planning guide highlights the transition from existing Task-based reporting to VoiceCall-based reporting. Existing custom automation and historical records need deliberate treatment.

Map provider conversation and call-leg identifiers, Salesforce record relationships, direction, timestamps, duration, dispositions, and recording references. Specify which events create a record and which update one. Transfers and conferences may produce multiple legs, so one call attempt does not necessarily equal one CRM row.

Decide whether historical data stays in place, is transformed, or remains in a separately accessible archive. Test representative old recordings and reports before removing packages or canceling vendor access. A link that works today may depend on a retained license or expiring authorization.

Recording, transcription, retention, and who may listen require a separate privacy and access review for the relevant workforce and locations. Feature availability does not itself establish permission to record or retain a conversation.

Use acceptance gates instead of generic percentages

A fixed “98% CRM sync” target would leave unexplained missing records. Reconcile the provider's eligible call events against the expected Salesforce records and classify every discrepancy as delayed, failed, intentionally excluded, or resolved. Define the denominator and acceptable delay with operations.

Separate technical call failures from busy numbers, unanswered calls, and other ordinary outcomes. Baseline screen-pop speed and audio quality on representative networks, then agree acceptance thresholds for the actual workflow. Neither a universal connection percentage nor a standard migration duration can establish readiness.

Before expanding the pilot

• Vendor confirms the replacement's supported, non-Open-CTI architecture
• Required inbound, outbound, transfer, voicemail, and callback cases pass
• Record matching and recording access respect user permissions
• Missing, duplicate, and delayed CRM records are detected and repaired
• Reports and downstream processes are checked against known examples
• Support owners and an incident escalation route are ready
• Number routing, cutover, and fallback have been rehearsed

Plan parallel validation with appropriate separate user groups; Salesforce documents contact-center membership constraints. Avoid two integrations writing the same activities without a deliberate deduplication design.

Rollback must cover number routing, licenses, configuration, and data created after cutover. Keeping an old package installed is only one dependency. An Open CTI fallback cannot be the recovery plan after retirement. Decommission only after dependencies and retained-data access have been checked.

Make the next decision from your actual setup

Discuss your Open CTI migration. Bring the installed package name and version, telephony provider, and the calling workflows you must preserve. Those details help distinguish a connector migration from a broader telephony change.