Calling the transition from Open CTI to Salesforce Voice a "migration" undersells both the effort and the opportunity.

That framing from people who have been through it captures something important: this is not a lift-and-shift. You are not moving the same thing to a new platform. You are changing how voice fundamentally works inside Salesforce, which means the project involves architecture decisions, data model changes, workflow rebuilds, and agent training, not just a configuration update.

That said, for many organizations, especially smaller service teams, migration is more approachable than expected when tackled in phases.

The teams that get into trouble are the ones that treat this as a purely technical project and skip the planning work. The teams that do it well start with a clear picture of what they have, make deliberate architecture decisions before writing a single line of configuration, and phase the rollout so the risk is manageable.

This guide walks through exactly that process.

What You Are Actually Moving Away From

Before you can plan the migration, you need to understand what Open CTI actually is and what Salesforce Voice replaces.

Open CTI is an integration surface. The telephony infrastructure it connects to, including carrier relationships, call quality, recording, and routing, remains the responsibility of the provider.

In practical terms, Open CTI was a JavaScript-based framework that let third-party phone systems embed a softphone panel inside the Salesforce UI. Your calls happened outside Salesforce. The Open CTI panel just surfaced them inside the browser.

With Open CTI, telephony lives outside Salesforce and is surfaced through integration. With Service Cloud Voice, Salesforce becomes the native voice workspace. Instead of embedding a third-party dialer, Service Cloud Voice takes closer control of the call lifecycle.

Salesforce Voice brings voice directly into Salesforce's native Omni-Channel engine, so calls are routable, loggable, and tied to the customer record in real time, sitting alongside every other channel in the agent's workspace.

Understanding that shift, from an integration surface to a native platform, is what frames every decision you will make during the migration.

The Data Model Change That Most Teams Miss

This is the most technically significant difference between the two platforms, and the one that catches teams off guard more than any other.

Open CTI stores call data as Tasks or Activities. Salesforce Voice uses the VoiceCall object. These are fundamentally different data structures. Historical data cannot be directly migrated.

What that means in practice: every report, dashboard, and workflow your team built on call activity in Salesforce was built on Task records. When you move to Salesforce Voice, the source of truth for call data becomes the VoiceCall object.

Your historical data stays in your org, but reporting models and object mappings will need to be adjusted when moving to the Service Cloud Voice record model. A data audit is recommended before migration.

To maintain continuity, you will need to design reporting that combines both data sources, often using tools like CRM Analytics or external BI platforms.

The practical implication: do not wait until go-live to figure out your reporting continuity plan. Build it into the pre-migration scoping work.

On the other side of this data model shift is a meaningful upgrade. Every interaction creates a native VoiceCall record connected directly to the customer's Contact, Case, and Account records. Transcripts, sentiment signals, and conversation outcomes become part of the Salesforce data model, making them accessible to reporting, automation, and AI.

Every call becomes a source of insight the business can learn from.

Phase 1: Audit Before You Touch Anything

The migration starts with documentation, not configuration. Before any platform decisions are finalized, you need a complete picture of your current Open CTI setup.

Inventory every customization. Open CTI implementations vary enormously. Some are simple screen pop configurations. Others involve complex custom JavaScript, multi-party call flows, supervisor monitoring, and deep integrations with external systems. Map each customization against partner contact center capabilities. In many cases, declarative replacements already exist.

That last point is significant. A large percentage of Open CTI customizations were created to fill gaps that a partner contact center now handles natively. That means many teams actually remove custom code during migration instead of adding more.

Document your call flows. Map every inbound and outbound call flow currently running in your Open CTI environment. Which queues exist? How is routing logic configured? What happens when a call is transferred? What supervisor capabilities are in use? All of this needs to be documented before it can be rebuilt.

Audit your telephony provider situation. Are you staying with your existing telephony provider using partner telephony, or moving to Amazon Connect as your bundled telephony layer? This decision shapes your entire migration architecture and needs to be made during Phase 1, not halfway through the project.

Identify your phone numbers. Document every number in use across your call center. If you are moving to Amazon Connect, those numbers can be ported, but porting takes time and varies by carrier. Flagging this early prevents it from becoming a go-live blocker.

Phase 2: Architecture Decisions

With the audit complete, you make the decisions that shape the rest of the project.

Choose your telephony model. Salesforce Voice supports three paths: Amazon Connect (turnkey), Partner Telephony with providers like Genesys, NICE, Vonage, or Five9, and bring your own telephony with your existing carrier. Each has different cost implications, configuration complexity, and long-term flexibility.

Amazon Connect gives you the deepest native integration with Salesforce Voice and the clearest path to Agentforce. Partner telephony preserves your existing carrier relationships and rates. Your call volume, existing contracts, and AI roadmap all feed into this decision.

Plan your VoiceCall reporting structure. Decide now which fields you need on the VoiceCall object to support your reporting requirements. Build those field definitions before you start configuring call flows, not after. Retroactively adding fields to an active VoiceCall setup is considerably more disruptive than getting the data model right from the start.

Design your Omni-Channel routing. Use Omni-Channel Flows and Record-Triggered Flows on the VoiceCall object to recreate existing workflows. If your Open CTI setup had skill-based routing, priority queues, or overflow handling, map those requirements to Omni-Channel configuration in Salesforce before you touch Amazon Connect.

Define your phased rollout plan. Most successful migrations do not cut over all agents on a single day. A phased approach, starting with a pilot group of agents on a non-production org, moving to a small production cohort, then rolling out to the full floor, significantly reduces go-live risk.

Phase 3: Amazon Connect Setup

If you are using Amazon Connect as your telephony layer, this phase covers the AWS side of the configuration before you bring Salesforce into the picture.

Set up your Amazon Connect instance. Create your Amazon Connect instance in the appropriate AWS region for your location. Confirm that the features you plan to use, including Contact Lens, real-time transcription, and any Amazon Lex IVR flows, are available in your chosen region.

Build your contact flows. Amazon Connect uses a visual contact flow designer to configure your IVR logic, queue routing, and call handling behavior. Rebuild your existing call flows in Amazon Connect first, and test them independently before connecting to Salesforce. Getting the telephony behavior right in isolation is easier than debugging it once the Salesforce integration is live.

Configure your queues and routing profiles. Create the queues that correspond to your agent groups or skill categories. Set up routing profiles that define which queues each agent handles and the priority order. These map directly to your Omni-Channel configuration on the Salesforce side.

Set up recording and Contact Lens if applicable. If you plan to use Amazon Connect Contact Lens for call analytics, quality scoring, or real-time sentiment, configure it at the Amazon Connect level before the Salesforce integration goes live. Contact Lens requires call recording to be enabled, so confirm your recording bucket configuration and retention policies are in place.

Phase 4: Salesforce Voice Configuration

With Amazon Connect configured and tested independently, you connect the two platforms and configure the Salesforce side.

Enable Service Cloud Voice in your Salesforce org. Work with your Salesforce account team to provision the Service Cloud Voice add-on. For new Agentforce Service organizations, note that Open CTI is deprecated and unavailable for newly created Agentforce Service orgs, so Salesforce Voice is the only path forward for any new org setup.

Connect Amazon Connect to Salesforce. The connection is established through the Salesforce Contact Center setup flow, which links your Amazon Connect instance to your Salesforce org. During this process, you configure the phone number associations, the agent experience settings, and the VoiceCall object behavior.

Rebuild your screen pop logic. In Open CTI, screen pops were typically configured in the call center definition file or through custom JavaScript. In Salesforce Voice, screen pops are configured natively through the agent console and Omni-Channel settings. Map each existing screen pop scenario to its Salesforce Voice equivalent.

Configure the agent workspace. Set up the Salesforce Voice widget in the agent console. Define which components agents see during a call, including customer records, open cases, Knowledge articles, and any Agentforce-powered next-best-action recommendations. This is also where real-time transcription display is configured if you are using it.

Rebuild supervisor features. Replace custom-built Open CTI supervisor features with built-in Salesforce Voice connector methods. Supervisor monitoring, call barging, and whisper coaching are all available natively in Salesforce Voice, but the configuration is different from custom Open CTI supervisor implementations.

Phase 5: Testing Before Go-Live

Never skip this phase. A migration that goes live without structured testing is a migration that discovers its problems in production, which is the worst possible place to find them.

Test the full call lifecycle end to end. Run an inbound call through the complete flow: IVR, queue, agent acceptance, hold, transfer, wrap-up, and VoiceCall record creation. Confirm that every step behaves as expected and that the VoiceCall record is correctly associated with the relevant Contact, Case, and Account.

Test edge cases explicitly. Abandoned calls, simultaneous transfers, voicemail handling, overflow to backup queues, and calls that come in outside business hours are all scenarios worth testing explicitly before go-live. These are also the scenarios most likely to expose configuration gaps.

Validate reporting. Run your key reports against VoiceCall data from your test calls. Confirm that the fields your team needs for performance reporting are populated correctly. Fix any gaps in the data model before agents are live on the platform.

Run a pilot with a small agent cohort. Before full rollout, run live production traffic through Salesforce Voice with a small group of agents, typically five to ten, while the rest of the team remains on the existing Open CTI setup. This gives you real-world validation without full-floor exposure.

Phase 6: Go-Live and Post-Migration

Cut over in waves, not all at once. Move agents from Open CTI to Salesforce Voice in groups. This limits the blast radius if something unexpected surfaces and gives your support team capacity to handle agent questions without being overwhelmed.

Keep the old setup running in parallel briefly. Do not decommission your Open CTI configuration the day you go live on Salesforce Voice. Maintain it as a fallback for a defined period, typically two to four weeks, so you have a rollback option if a critical issue is discovered post-launch.

Run parallel reporting for the first month. Generate your standard performance reports from both the old Task-based records and the new VoiceCall records for the first month after go-live. This catches any reporting gaps and builds confidence that the new data model is capturing everything correctly before you retire the old reporting setup.

Train agents before go-live, not after. The agent workspace in Salesforce Voice looks and behaves differently from an embedded Open CTI softphone. Agents need hands-on training in a sandbox environment before they handle live calls on the new platform. Budget at least two to four hours of structured training per agent, more for power users and team leaders.

Where Implementation Partners Make the Biggest Difference

The technical steps above are well-documented. What is harder to document is the accumulated judgment that comes from having done this migration in multiple environments with different telephony setups, different levels of Open CTI customization, and different organizational change management needs.

A qualified Salesforce and Amazon Connect implementation partner brings three things that are hard to replicate internally: experience with the architecture decisions that create problems six months after go-live, relationships with Salesforce and AWS account teams that can accelerate issue resolution, and a structured project methodology that keeps the migration on track without the team rediscovering solved problems.

La Confianza Technologies works specifically at the intersection of Salesforce and Amazon Connect, with contact center migration experience across industries.

If you are starting to scope your Open CTI migration and want a clear assessment of what the project involves for your specific environment, the right starting point is a conversation before you commit to a timeline or architecture.

Common Questions around the topic

Will we lose historical call data when we migrate?

No. Historical data stored in Salesforce, such as Tasks, Activities, or custom objects, remains in your org. What changes is the reporting model. Going forward, new call activity is captured in VoiceCall records rather than Tasks. You will need a plan for combining both data sources in your reporting until the historical Task data is no longer relevant to your team's metrics.

Do we have to rebuild all our Open CTI customizations from scratch?

Not necessarily. Many Open CTI customizations were created to fill gaps that a partner contact center now handles natively, meaning many teams actually remove custom code during migration instead of adding more. A thorough audit of your current customizations, mapped against Salesforce Voice's native capabilities, typically reveals that a significant portion can be replaced with declarative configuration.

Can we run Open CTI and Salesforce Voice in parallel during the migration?

To a limited extent. You can maintain your Open CTI setup while piloting Salesforce Voice with a subset of agents, which is the recommended approach for phased rollouts. Running both at full scale simultaneously is not a supported long-term architecture.

How do we handle phone number porting to Amazon Connect?

Amazon Connect supports number porting from most carriers. The process involves submitting a porting request through AWS, providing carrier authorization documentation, and coordinating a porting date. The timeline varies by carrier but typically runs two to four weeks. Start the porting process early in the migration project so it does not hold up your go-live date.

What is the biggest mistake teams make during this migration?

Skipping the audit phase and going straight to configuration. Teams that start building in Amazon Connect before they have fully documented their current Open CTI setup inevitably discover requirements they did not account for, which means rework mid-project. The audit is not overhead. It is what makes the rest of the project predictable.

AWS and Salesforce have said they will publish detailed migration guidance in August 2026. Should we wait for that?

AWS and Salesforce will publish detailed migration guidance and timeline in August 2026. Reading that guidance when it publishes is worthwhile, particularly for teams using the Amazon Connect CTI Adapter. But waiting to start your planning until guidance is published is not advisable. The scoping work, architecture decisions, and internal alignment needed before you can act on any guidance takes months. Start now, use the guidance to validate your approach when it arrives.

‍