The first two paths in this series assume that the organization is fundamentally satisfied with its current phone system. Path 1 keeps the provider and moves the Salesforce integration to Salesforce Voice with Partner Telephony. Path 2 keeps the provider but replaces Open CTI with an API-based integration.

Path 3 is different because the existing contact center platform itself is being replaced. With Agentforce Contact Center, Salesforce becomes much more than the CRM connected to the phone system. Salesforce describes Agentforce Contact Center as its native contact-center offering and, with native voice, Salesforce owns the voice media stream rather than relying on a third-party CCaaS provider to provide the telephony platform. Salesforce can provision phone numbers, manage voice interactions, route work through Omni-Channel, store interaction data and recordings, and connect voice more directly with the rest of the Salesforce service experience.

For an organization that was already questioning whether its existing CCaaS platform was the right long-term fit, the Open CTI retirement creates a reasonable point to evaluate this option. Rather than spending time and money rebuilding an integration to a platform the business may want to replace in another year or two, the company can consider moving the contact center itself onto Salesforce.

That is a very different project from replacing Open CTI. The existing provider may currently own routing, IVRs, queues, recordings, phone numbers, carrier connectivity, outbound functionality, supervisor tools, reporting and other operational capabilities. Moving to Agentforce Contact Center means deciding how each of those functions will work in the Salesforce environment. The Salesforce implementation and the contact-center migration effectively become the same program.

Where this fits in Salesforce’s guidance

Agentforce Contact Center with native telephony is Salesforce’s own destination for organizations that want telephony inside Salesforce. Confirm native telephony availability and the supported carrier model for each operating region.

The first question is whether you actually want to replace the contact center platform

Open CTI retirement by itself is not a reason to replace a phone system that the business likes. If routing works well, agents are productive, supervisors understand the tools, reporting is trusted and the company has no meaningful complaints about the existing provider, then moving the entire contact center simply because Open CTI is retiring may introduce far more change than is necessary. Path 1 or Path 2 would normally deserve evaluation first.

The argument for Path 3 becomes stronger when the current provider has broader problems that already need to be solved. Perhaps the business is unhappy with reporting, outbound dialing, agent experience, reliability, contract economics or the pace of innovation. Maybe voice and digital channels are fragmented across several systems. The organization may already be investing heavily in Salesforce Service and wants routing, customer history, voice interactions and AI capabilities to operate more cohesively.

A readiness assessment should therefore separate two questions that can easily become mixed together. The first is how to replace Open CTI. The second is whether the existing CCaaS platform should still be part of the future architecture. The answer should guide whether the organization invests in a replacement platform or a new integration to its existing provider.

One of the first things we would do in a Path 3 assessment is document what the current CCaaS platform actually does for the organization today. That goes well beyond answering and routing calls. The inventory needs to include IVRs, queues, skills, outbound workflows, recordings, quality management, workforce-management dependencies, supervisor tools, phone numbers, carriers, compliance controls, digital channels, dashboards, integrations and any provider-specific capabilities the business has come to rely on.

The tighter architecture changes both the Salesforce and telephony operating model

In Paths 1 and 2, much of the telephony environment can remain where it already lives. Path 3 moves more of that responsibility into Salesforce. Routing, queue design, interaction data, recording policies and the agent experience become part of the Salesforce contact-center architecture rather than functions handled primarily in a separate CCaaS platform.

That creates opportunities, but it also changes where the contact-center team performs work. Existing queue and skill configurations may currently live entirely within the CCaaS platform. In Agentforce Contact Center, routing design becomes part of the Salesforce Omni-Channel architecture. IVR behavior can also be implemented through Salesforce flows, including decisions around routing, recording and transcription. A migration therefore cannot begin with an assumption that the existing CCaaS configuration will simply be imported into Salesforce. The current routing model first needs to be understood as a set of business requirements and then redesigned for the new platform.

The same applies to interaction data. A legacy environment may create Tasks after calls, store provider-specific interaction objects, or send call data into a data warehouse. Agentforce Contact Center centers voice activity around Salesforce’s VoiceCall model. Recordings can also be stored on the Salesforce platform, which means retention requirements, file storage, data exports, reporting and downstream analytics should all be reviewed before large call volumes begin accumulating in the new model.

The dependency, support and broader communications model deserve careful review

One consequence of moving the contact center itself into Salesforce is that Salesforce becomes part of the critical path for both CRM and voice. With the native Agentforce Contact Center voice offering, Salesforce directly owns the voice media stream and manages the voice experience from number provisioning through the interaction itself. This is very different from an architecture where Salesforce is connected to an independent CCaaS platform.

We would not describe that as meaning every Salesforce incident automatically takes every phone call offline, because outages can affect different services in different ways. It does mean that the organization is deliberately placing more of its communications infrastructure and CRM infrastructure into the same technology stack. For a business that requires independent telephony during a Salesforce interruption, test the relevant failure scenarios. Salesforce documents regional failover for BYOC media services; resilience depends on the affected component and deployment.

The operational support model changes as well. Prospective customers should examine the support experience, escalation paths and operational expertise for carrier issues, SIP problems, call quality, number routing, one-way audio and regional failures. Apply the same criteria to Salesforce and competing CCaaS providers.

For a 24x7 operation handling large call volumes, we would want detailed answers around Severity 1 voice incidents, carrier escalation, call-quality investigation, customer-visible telemetry and the support level required to meet the organization’s expectations. A proof of concept can tell you whether calls work; the support discussion should tell you what happens when they do not.

Many organizations also need to look beyond the contact center when evaluating consolidation. The agents being migrated may represent only part of the company’s communications environment. The rest of the business may already use a separate UCaaS platform for corporate phone numbers, desk phones, internal calling, conferencing and other unified-communications functions. Moving the contact center into Salesforce can result in customer-service agents using Salesforce for telephony while employees elsewhere remain on a different communications platform.

That may be perfectly acceptable, particularly if the contact center already operates separately from corporate telephony. Other organizations place considerable value on having UCaaS and CCaaS supplied through the same platform, with employees and contact-center agents participating in one communications environment. For those companies, the comparison should include the broader communications architecture rather than focusing only on the contact-center feature set.

Carrier and number strategy remain important

A company may decide to replace its contact-center platform without necessarily giving up its existing carrier relationships or phone numbers. Salesforce can provide native numbers and telephony services directly in supported markets, and organizations can also evaluate carrier and number-porting strategies based on geography, existing contracts and operational requirements.

Salesforce has also introduced a Bring Your Own Carrier model for Agentforce Contact Center. Under that architecture, an organization may retain a compatible carrier relationship and connect it to Salesforce through supported SIP trunks while Salesforce becomes the contact-center platform. For a large company, that distinction can be significant. Carrier migrations and number porting introduce their own operational risk, and retaining the carrier is an option only where Salesforce’s security, interoperability and geographic requirements are met.

Licensing is a much larger part of Path 3

The licensing model needs to be understood before the project moves very far into design. Agentforce Contact Center is a broader Salesforce contact-center offering rather than a small integration add-on, and the published pricing reflects that. Actual contracted pricing may differ based on enterprise agreements, volume and negotiated commercial terms, but the scale of the licensing decision should be modeled early.

For a 500-agent or 1,500-agent operation, this is not a minor Salesforce add-on. The licensing model needs to be considered alongside whatever costs are being retired from the existing CCaaS provider. The relevant financial comparison should include existing CCaaS licenses, required Salesforce base entitlements and Agentforce Contact Center licensing, without double-counting capabilities included in a bundle, telephony usage, workforce or quality-management requirements, implementation costs, carrier expenses and the cost of operating the environment after launch.

Platform-license customers need the same scrutiny discussed in Path 2. An organization running an industry-specific application on Platform or OEM licensing may be looking at a substantial Salesforce licensing change before contact-center licensing is added. Path 3 can still make sense if the goal is a broader move toward Salesforce as the service and contact-center platform, but it should be evaluated as a transformation with a corresponding business case rather than as the replacement for an Open CTI adapter.

What the project tends to look like

A Path 3 project usually begins with a longer discovery period than either of the previous options because there are two existing environments to understand: Salesforce and the current CCaaS platform. On the contact-center side, we would document IVRs, queues, skills, routing rules, hours of operation, phone numbers, carrier relationships, recording policies, outbound processes, supervisor tools, quality processes, workforce-management dependencies and operational reporting. On the Salesforce side, the same assessment needs to identify current Open CTI behavior, record matching, automation, reporting, permissions and integrations that react to contact-center activity.

The design phase converts that current state into a Salesforce-native operating model. Routing and queue design need to be rebuilt. IVRs need to be designed. Phone-number and carrier strategy needs to be established. Recording and transcription policies need to be configured. Salesforce security, permissions and applications need to support the new contact-center users. Reporting and supervisor workflows need to be redesigned, and any digital channels being consolidated into the new platform need their own requirements.

The integration inventory often extends beyond Salesforce. A mature contact center may send recordings to compliance systems, call data to data warehouses, schedules to workforce-management systems or customer events to other enterprise applications. Replacing the provider means those integrations may need to be replaced or retired as well.

Testing should include more than feature validation. Call quality, inbound routing, outbound calling, transfers, conference calls, hold behavior, recordings, transcription, caller ID, after-call work, failure handling and supervisor visibility all need to be exercised under realistic conditions. Business users should validate the same edge cases that occur in production today rather than a simplified demonstration workflow.

For a large migration, we would normally expect some form of controlled pilot before a broad cutover. A smaller team may be able to operate on Agentforce Contact Center while the rest of the organization remains on the existing provider, subject to a supported number-routing and coexistence design. That provides an opportunity to compare call quality, agent workflows, Salesforce data, reporting and operational support in a real environment before thousands of calls are moved.

A hypothetical example

Consider an organization with approximately 400 customer-service agents using an established CCaaS provider connected to Salesforce through Open CTI. The current platform was selected years ago. Call quality is acceptable, but the business has gradually become frustrated by having routing and customer-service operations split between systems. Agents work almost entirely in Salesforce, supervisors regularly need Salesforce data while managing interactions, and the organization is already using Service Cloud heavily for cases, digital channels and knowledge. The CCaaS contract is also approaching renewal.

In this environment, simply replacing Open CTI with another integration may preserve an architecture the company already wants to move away from. Discovery identifies dozens of queues, several IVR trees, a meaningful phone-number estate, call recording requirements, integrations into the company’s data warehouse and a workforce-management process currently tied to the existing provider. The Salesforce environment also contains several Flows that respond to completed call activities.

The migration project would need to rebuild the routing and IVR design in the Salesforce architecture, establish the carrier and number strategy, redesign call-related automation around VoiceCall, implement recording and transcription requirements, recreate operational reporting and determine what happens to workforce management. A small customer-service group might move first using a limited set of numbers and queues, operating for several weeks while the project team compares call quality, routing behavior, agent productivity, Salesforce data and reporting with the legacy environment.

The schedule would need to follow discovery, carrier confirmation and a tested rollout plan. The benefit is not simply that Open CTI disappears. The company ends the project with a materially different contact-center architecture.

Where Path 3 tends to fit

Path 3 is most compelling when Open CTI retirement coincides with a broader reason to reconsider the existing CCaaS provider. Organizations already heavily invested in Salesforce Service, Omni-Channel and digital engagement may see significant value in bringing customer data, routing, voice interactions and AI capabilities into one Salesforce operating model.

The analysis should extend beyond features and licensing. Moving native voice into Salesforce changes the failure domain, the support model and potentially the company’s broader communications architecture. An organization that needs its phone system to operate independently of Salesforce may value the separation offered by another path. A company whose employees already share a common UCaaS and CCaaS platform may also need a compelling reason to split the contact center away from the corporate communications environment.

None of those considerations make Agentforce Contact Center the wrong choice. They belong in the same evaluation as AI capabilities, native CRM integration and consolidation benefits. A contact-center platform is operational infrastructure, and the decision needs to account for what happens during an outage or support incident just as seriously as what happens when everything is working normally.

CommCorrect’s role is to make that comparison before a platform decision is made. If Agentforce Contact Center is the right destination, we can help scope and execute the migration across the Salesforce and contact-center workstreams, including architecture, routing, data, integrations, testing, rollout and transition from the existing provider, with responsibilities agreed across CommCorrect, Salesforce and any implementation partners. If the assessment shows that replacing the current CCaaS platform adds cost and risk without solving a meaningful business problem, we would recommend one of the less disruptive paths instead.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service