For many Salesforce customers, Open CTI has been part of the business phone integration for so long that it no longer receives much attention. It sits behind the phone integration employees use every day and supports familiar workflows such as click-to-dial, screen pops, call logging and access to telephony controls directly within Salesforce. In more mature environments, it may also be connected to routing logic, Salesforce automation, reporting, call dispositions, recordings and a variety of custom processes that have been added over the years.

Salesforce has now placed Open CTI into maintenance mode and scheduled it for retirement on February 28, 2028. Salesforce has also confirmed that Open CTI implementations will no longer function after the retirement date, which means organizations using it today will eventually need to replace the integration architecture rather than simply continue operating it without support.

This reaches beyond the contact center

Any business with a phone system integrated into Salesforce should check whether that integration uses Open CTI. Insurance adjusters, case managers, accounting and finance staff, and operations teams may rely on it even when they do not use an outbound dialer or take calls from a shared queue. An employee may simply have a desk phone or softphone with an individual direct inward dialing (DID) number, click to dial from a record, see a screen pop when someone calls, and log call notes against the relevant Salesforce record.

If those functions depend on Open CTI, they need a replacement before retirement. The dependency matters, not the department name or call volume. The underlying phone service may continue working while the Salesforce integration stops. Some of these employees may use Salesforce Platform or industry-application licenses rather than Service Cloud, so the assessment must check their actual entitlements and workflows before recommending a Voice migration.

Salesforce is understandably encouraging customers to move toward Salesforce Voice and its newer contact center architecture, but that is not the only technical path available. Depending on the existing telephony platform, desired employee experience, licensing considerations and the amount of change the organization is prepared to take on, there are several different ways to move away from Open CTI.

We group the decision into five practical paths. These are CommCorrect’s planning categories, not Salesforce’s numbered migration paths.

The five paths beyond Open CTI

1. Keep your current telephony provider and move to Salesforce Voice

For organizations that are happy with their current CCaaS or telephony provider, one option is to keep that platform in place while replacing Open CTI with Salesforce Voice using supported partner telephony. This is commonly described as a BYOT, or Bring Your Own Telephony, approach.

The benefit is that the organization does not have to replace the underlying contact center platform simply because Open CTI is retiring. Existing routing, carrier relationships, phone numbers and many telephony capabilities may be able to remain in place while Salesforce becomes more deeply involved in the agent experience and voice data model.

The tradeoff is that this should not be viewed as a simple adapter upgrade. Moving from an established Open CTI implementation into Salesforce Voice can require changes to the Salesforce data model, routing, presence, call activity, automation, reporting, custom components and agent workflows. There may also be incremental Salesforce licensing costs, depending on existing entitlements and the proposed package.

2. Keep your current telephony provider and move to a separate integration

A second option is to keep the existing telephony provider but replace Open CTI with an integration that does not use Salesforce Voice. The exact product and version must be verified to work without either Open CTI or Salesforce Voice; an API, managed package or browser extension does not establish that by itself. In some cases, the telephony provider may already offer an out-of-the-box Salesforce integration that can replace much of the functionality currently delivered through Open CTI. Where a suitable packaged integration does not exist, a custom solution can be built using the provider’s APIs, Salesforce APIs, middleware, browser extensions or other supported integration mechanisms.

This approach can be attractive for organizations that primarily need Salesforce and the communications platform to exchange customer and interaction data without moving the entire telephony experience into Salesforce. It may involve less Salesforce-specific migration work and can avoid the additional Salesforce Voice licensing expense. The user-experience tradeoff is that agents may continue using the contact center provider’s interface for some or all telephony controls rather than having the full voice experience embedded natively inside Salesforce.

The separation can also have architectural benefits. If telephony continues to operate primarily within the CCaaS platform, a Salesforce outage does not necessarily mean the phone system itself stops working. Salesforce-dependent capabilities such as CRM lookups, screen pops, logging and automation may be unavailable, but the communications platform can remain operational if agents have an independent way to access it.

3. Replace the existing provider with Agentforce Contact Center

Another path is to use the Open CTI retirement as an opportunity to replace the current CCaaS provider altogether and move voice into Salesforce through Agentforce Contact Center. This represents a much broader architectural change. Rather than Salesforce acting primarily as the CRM while a separate provider owns the contact center platform, more of the voice experience, routing, interaction data and agent workflow moves into the Salesforce ecosystem.

For an organization already considering replacement of its current contact center provider, this may be an appropriate time to evaluate that model. It can create a more unified Salesforce experience, but it is also one of the largest migration efforts available. Routing, phone numbers, carriers, recordings, reporting, supervisor tools, Salesforce automation and agent workflows can all be affected, and the additional Salesforce licensing needs to be evaluated as part of the business case.

4. Move to a new telephony provider and use Salesforce Voice

Some organizations will determine that they want to change providers but still prefer Salesforce Voice as the Salesforce integration architecture. In this scenario, the company selects a new supported telephony provider and implements Salesforce Voice usually using a BYOT model. Salesforce-managed Amazon Connect is a related non-BYOT option, as the mapping below explains. This combines two significant projects: replacing the existing contact center platform and replacing Open CTI.

There may be good reasons to take this approach. If the current provider already has limitations around routing, outbound dialing, reporting, reliability, AI capabilities or cost, it may make little sense to invest in migrating that provider into Salesforce Voice only to replace it shortly afterward. The project is larger because vendor selection, routing, phone numbers, licensing, integration work, Salesforce configuration, testing and user adoption all become part of the same migration.

5. Move to a new telephony provider and use a separate Salesforce integration

The fifth path is to select a new business phone or contact center provider without moving to Salesforce Voice. This is particularly relevant when a prospective provider already offers an out-of-the-box integration with Salesforce that provides the level of CRM connectivity the organization needs. If that packaged integration meets the business requirements, the company may be able to modernize both the telephony platform and the Salesforce integration without introducing the licensing and Salesforce migration effort associated with Salesforce Voice.

If the selected provider does not have a suitable packaged integration, a custom API architecture remains another possibility. This approach can preserve clearer boundaries between Salesforce and the communications platform while still allowing customer, call and activity data to move between the systems. The main question is how much of the agent experience needs to live inside Salesforce.

How our paths map to Salesforce’s migration paths

Salesforce’s four published migration paths cover moves to Salesforce Voice, including native telephony for Agentforce Contact Center. They do not cover every alternative to Open CTI. CommCorrect’s five paths also distinguish whether you keep or replace the provider and include API integrations outside Salesforce Voice.

Salesforce Path 1: Salesforce Voice with Partner Telephony - CommCorrect Path 1 when retaining a supported provider. The same partner-telephony model can support Path 4 when selecting a new provider with a Salesforce Voice-certified package.

Salesforce Path 2: Salesforce Voice with Partner Telephony from Amazon Connect - CommCorrect Path 4 when moving to customer-owned Amazon Connect.

Salesforce Path 3: Salesforce Voice with Amazon Connect - A related option within CommCorrect’s broader Path 4 provider-change decision, but not BYOT: Salesforce provisions and manages the Connect instance in a Salesforce-owned AWS account, and telephony billing is through Salesforce.

Salesforce Path 4: Salesforce Voice (Native Telephony) - CommCorrect Path 3: Agentforce Contact Center with native telephony.

CommCorrect Paths 2 and 5 sit outside these four Salesforce migration paths. Their Open CTI-free, non-Voice integration must be independently verified for the exact product and version; the Salesforce guide does not validate those alternatives.

Packaged API integrations can change the equation

One of the most important things to evaluate during the readiness process is whether the existing provider, or a provider being considered as a replacement, already has a modern Salesforce integration that does not depend on Open CTI. This is easy to overlook if the migration discussion begins with Salesforce Voice.

An organization may discover that the provider it already uses has a newer integration path available, or that a competing platform offers one that satisfies the business requirements without requiring Salesforce Voice.

The integration still needs to be evaluated for screen pops, call logging, outbound dialing, recordings, dispositions, reliability, reporting and the overall agent experience. In some cases, the provider integration may cover most requirements with only a small custom layer needed for the remaining gaps.

Migration effort and licensing belong in the architecture decision

The five paths have very different implementation and long-term cost profiles. Any path that introduces Salesforce Voice involves more than replacing JavaScript APIs. Depending on the current architecture, it can involve routing and presence changes, a different Salesforce voice data model, automation updates, reporting changes, security configuration and redevelopment of functionality that previously depended on Open CTI.

Moving to Agentforce Contact Center can expand the scope further because the underlying contact center platform is changing at the same time. Both approaches can also introduce additional Salesforce licensing costs that need to be considered across the full population of affected employees. At enterprise scale, even relatively modest per-user changes can materially affect the economics of the migration.

An API-based approach may have a different cost profile. If a provider already offers an out-of-the-box Salesforce integration, the migration effort may be substantially lower. If custom work is required, there will still be implementation and ongoing support costs, but the organization may avoid purchasing Salesforce Voice licenses for every user. The comparison should include several years of total cost rather than the implementation project alone.

CommCorrect can help determine the path and execute the migration

CommCorrect Technologies is offering a free Open CTI Readiness Assessment to help organizations understand the available options before committing to a specific architecture. The scope of the free assessment should be agreed at the outset; detailed technical discovery and implementation are separately scoped. The assessment begins with the environment that exists today. We also look at whether the existing provider already offers a viable non-Open-CTI integration and whether alternative providers may offer packaged integration options worth considering.

CommCorrect can also remain involved after the assessment, with implementation responsibilities agreed across our team, the provider and any delivery partners. If Salesforce Voice is the right answer, we can design and execute the Salesforce Voice migration. If the organization decides to move to a new phone or contact center provider, we can help evaluate, select and migrate to the new platform. If the best option is to keep the existing provider but replace Open CTI with an API-based architecture, we can explore designing and building the custom Salesforce integration when an appropriate out-of-the-box option is not available.

The February 2028 Open CTI retirement means every organization using the framework needs a replacement strategy, but it does not mean every organization needs the same replacement. Begin that evaluation before the next provider renewal or budget cycle, with time for testing and rollout before retirement.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service