Open CTI is retiring.
Let's plan your move.

Salesforce has scheduled Open CTI for retirement on 28 February 2028. Existing implementations are already in maintenance mode, with no new features or enhancements, and newly created Agentforce Service orgs cannot implement it. After the retirement date Open CTI implementations will no longer function, so your replacement needs to be live, tested and adopted before then.

If your agents make or take calls through a softphone embedded in Salesforce that is not Salesforce Voice, it is likely built on Open CTI. Check your call centre definitions and installed telephony packages in Setup, or ask your telephony provider. We confirm this in discovery and identify every team, process and integration that relies on it.

Possibly. If your provider offers a generally available, supported Salesforce Voice or Partner Contact Center integration, you may be able to retain the telephony platform and change the Salesforce integration layer. Feature coverage, availability in your region and commercial terms must be confirmed with the provider, so we assess this before recommending a route.

No. Amazon Connect is one option, either as an environment you already run or provisioned through Salesforce. Supported partner integrations and Salesforce-native contact centre telephony are alternatives. We recommend a route based on your requirements, existing contracts and how much of the telephony operation you want to manage.

Custom code written against the Open CTI API will not carry over automatically. We catalogue each customisation, such as screen pops, record creation, call logging and integrations, then decide whether it is replaced by standard functionality, rebuilt for the new integration or retired because it is no longer needed.

Often, but it depends on your current and target carriers. If you retain your provider, numbers usually stay where they are. If the telephony platform changes, numbers may need porting, which has its own lead times and constraints. We identify number requirements early so they are built into the plan, rather than assumed.

Existing Salesforce records normally remain in your org. Recordings are stored according to your current provider's setup, so access after migration, export options and retention obligations need confirming with that provider. We document these requirements during assessment. Historical data migration is not automatic and is scoped separately where needed.

We validate in a sandbox first, then test the call scenarios your business depends on end to end: inbound and outbound calls, routing, transfers, screen pops, record creation, permissions and reporting, including failure scenarios. A pilot with representative users follows, and go-live only proceeds against agreed readiness criteria.

Usually, yes. Phasing by team, site or call type reduces risk and lets early feedback improve later waves. It does require planning for a period where both integrations may run, including routing, reporting and supplier arrangements. Whether phasing is feasible, and how, is decided during design.

There is no standard timeline. Duration depends on the complexity of your current setup, whether the provider changes, the number of users and sites, the level of customisation, procurement, testing and how you phase the rollout. The assessment produces a sequenced plan based on your environment.

The main factors are the migration route, the number of call journeys and customisations to rebuild, integrations, data and reporting requirements, testing scope, the rollout approach and the support you need afterwards. Licensing and telephony charges come from Salesforce and your provider. We scope costs once the assessment establishes the work.

We stay involved through stabilisation to resolve launch issues, support adoption and hand over documentation and operational knowledge. Beyond that, we can provide ongoing support and optimisation, including later phases such as transcription or AI assistance, with the scope agreed to fit your internal team.