Technical guide
Open CTI retirement: a technical migration guide
Salesforce Open CTI retires on 28 February 2028. Salesforce states that Open CTI implementations will no longer function after that date.
If your organisation uses an Open CTI adapter, you need to select a supported replacement and validate the Salesforce processes connected to it. Keeping your telephony provider may be possible; keeping the existing integration unchanged is not the migration plan.
This guide covers what to identify, what to decide and what to test.
What is Open CTI?
Open CTI is Salesforce's JavaScript API for integrating third-party telephony with its user interface. Adapters use it for functions such as screen pops, click-to-dial, call controls and call logging.
Open CTI is the integration framework. It is not your carrier or the entire phone system.
That distinction matters: its retirement affects integrations that depend on the framework. It does not mean every connected telephony platform is being retired.
What changes on 28 February 2028?
| Status | Meaning |
|---|---|
| Maintenance mode | Salesforce is no longer adding Open CTI features or enhancements. |
| New-org restriction | Newly created Agentforce Service orgs cannot implement Open CTI. |
| Retirement | Salesforce states that Open CTI implementations will no longer function after 28 February 2028. |
Do not use the retirement date as your production cutover date. Leave time to resolve issues and stabilise the replacement.
Source: Salesforce Open CTI retirement notice [1].
Why is Salesforce retiring Open CTI?
Salesforce describes the change as a move towards a more integrated service architecture, with voice connected to its platform and AI capabilities.
For migration planning, the practical implication is straightforward: assess the integration and its dependencies, rather than treating this as a softphone UI replacement.
Source: Salesforce retirement explanation [2].
How do I check whether we are affected?
Start with the integration actually used by your agents:
- Identify the telephony package, adapter and supplier.
- Review Call Center configuration, assigned users and the softphone implementation.
- Inspect custom telephony code for references to Open CTI APIs, including
sforce.opencti. - Ask the supplier to confirm the integration type and supported migration route in writing.
A phone panel inside Salesforce does not, by itself, prove that it uses Open CTI. Equally, the absence of API references in your own code does not exclude a dependency inside a managed package.
Record the package version, user groups, customisations and supplier response before selecting a replacement.
What do Salesforce Voice and Service Cloud Voice mean?
Service Cloud Voice is the former name used for Salesforce Voice offerings. Salesforce now also uses Partner Contact Center and Agentforce Contact Center terminology.
These names do not describe one interchangeable package.
| Term | How to interpret it during migration |
|---|---|
| Salesforce Voice / Service Cloud Voice | Names you will encounter in existing deployments, documentation and supplier integrations. |
| Partner Contact Center | The partner-based contact centre offering, including supported external telephony models. |
| Agentforce Contact Center | Salesforce's unified contact centre offering, including native telephony. |
| Agentforce | AI capabilities whose scope and licensing must be assessed separately from the integration migration. |
Confirm the exact product, telephony model, regional availability and licences in the proposed design.
Source: Salesforce migration-path terminology [3].
Which migration route should we choose?
Salesforce documents four routes:
| Route | Starting point | Key check |
|---|---|---|
| Supported partner telephony | You want to retain an existing telephony provider. | Does the provider offer a supported, generally available Salesforce Voice integration? |
| Your own Amazon Connect environment | You already operate Amazon Connect or want to manage the AWS environment. | Who owns the AWS configuration, integration and ongoing support? |
| Salesforce-provisioned Amazon Connect | You want the Salesforce-provisioned Amazon Connect model. | Does its configuration, packaging and operating model fit your requirements? |
| Salesforce-native telephony | You want Salesforce to provide the telephony service end-to-end. | Is the offering available in your region and suitable for your requirements? |
Amazon Connect is not mandatory for every migration.
For a custom-built adapter, decide whether to build and maintain a supported connector or adopt another supported route.
Sources: Salesforce migration paths [3] and partner migration guidance [4].
What needs to be assessed?
Create a dependency register. For each item, record its current behaviour, target implementation, owner and acceptance test.
| Area | What to capture |
|---|---|
| Adapter and custom code | Package versions, API usage, custom components and supplier dependencies. |
| Call journeys | Inbound, outbound, IVR, queues, transfers, callbacks, voicemail and out-of-hours handling. |
| Routing and presence | Routing ownership, skills, availability, capacity and status synchronisation. |
| Screen pops | Caller matching, multiple matches, unknown callers and conditional navigation. |
| Records and automation | Task creation or updates, related records, fields, flows, triggers and external integrations. |
| Reporting | Reports and dashboards that depend on existing call records or field values. |
| Recordings and transcripts | Storage, access, retention, historical links and export requirements. |
| Identity and access | Authentication, user mapping, permission sets and recording access. |
| Endpoints and network | Browsers, headsets, virtual desktops, connectivity and relevant provider requirements. |
| Suppliers and contracts | Connector support, licences, number retention or porting, support ownership and lead times. |
Not everything requires replacement. Identify what changes before rebuilding processes that can remain.
What happens to call records and reports?
Salesforce Voice uses the VoiceCall object. Existing Open CTI implementations may log activity to Tasks or vendor-specific objects.
Review automation and reporting that assume the old record structure.
Choose an explicit approach: adapt reports to the target data model, preserve required Task behaviour through a supported flow, or combine the two during transition.
Do not assume historical records, recording links or custom fields transfer automatically.
Source: Salesforce migration FAQ [5].
What will the migration cost?
Compare the full current and proposed costs:
- Required Salesforce and voice licences.
- Telephony-provider charges and usage.
- Optional capabilities and add-ons.
- Implementation, integration and testing.
- Temporary overlap between old and new services.
- Ongoing administration and support.
A published per-user price is not a complete project cost.
Whether the migration costs more depends on your existing agreements, selected route and implementation scope. Confirm inclusions and exclusions with Salesforce and the telephony provider.
Source: Salesforce UK pricing [6].
When should we start?
Start the dependency assessment now. Schedule production rollout after you have confirmed the route, supplier commitments, budget and testing requirements.
Work backwards from an internal completion date before retirement:
- Allow for stabilisation.
- Define rollout and contingency arrangements.
- Schedule pilot and acceptance testing.
- Estimate configuration and integration work.
- Resolve procurement, licensing and supplier dependencies.
The longest external dependency can determine the schedule. User count alone is not a reliable estimate of migration effort.
How should we test and cut over?
Test complete call journeys, including the Salesforce records and automation they produce.
At minimum, validate:
- Incoming and outgoing calls.
- Caller matching and screen pops.
- Queues, presence, transfers and callbacks.
- Call records, relationships and downstream automation.
- Recording access and permissions.
- Critical reports.
- Relevant failure and recovery scenarios.
Define expected results and go-live criteria before the pilot.
Salesforce's migration FAQ recommends retaining the Open CTI package until the Voice route has been validated in production for at least 30 days. It also warns against assigning the same representative to both contact centres simultaneously.
Confirm how coexistence works for your selected solution. Retaining the package is not the same as having a tested rollback process.
Source: Salesforce migration FAQ [5].
What should we do next?
Produce these five outputs:
- A verified inventory of Open CTI usage.
- A dependency register with owners.
- A supported migration route with confirmed prerequisites.
- A costed implementation and test plan.
- A rollout plan with acceptance and contingency criteria.
RocketCX helps assess dependencies, select the migration route and plan implementation.
Explore RocketCX's Open CTI migration services
Official references
- [1] Salesforce Open CTI retirement notice
https://help.salesforce.com/s/articleView?id=005306437&language=en_US&type=1 - [2] Salesforce retirement explanation
https://help.salesforce.com/s/articleView?id=005317712&language=en_US&type=1 - [3] Choose your migration path
https://trailhead.salesforce.com/content/learn/modules/open-cti-to-voice-migration/choose-your-migration-path - [4] Replace Open CTI with Salesforce Voice with Partner Telephony
https://help.salesforce.com/s/articleView?id=service.cti_migrate_voice_pt.htm&language=en_US&type=5 - [5] Open CTI migration FAQ
https://help.salesforce.com/s/articleView?id=service.cti_migrate_faq.htm&language=en_US&type=5 - [6] Salesforce UK voice pricing
https://www.salesforce.com/uk/service/call-center-integration/voice-pricing/