TL;DR | The Highlights
- Zendesk can be a strong support platform. But when sales, customer success, and other customer-facing teams operate in Salesforce, keeping service separate can introduce complexity that grows with the business.
- The warning signs aren’t always obvious: agents switching between systems for context, increasingly complicated integrations, fragmented reporting, and changes that take more coordination than they should.
- Moving to Agentforce Service (formerly Service Cloud) can bring service workflows closer to the customer data and business processes already managed in Salesforce. The value isn’t simply consolidation; it’s what teams can do with that connection.
- AI makes the architecture decision more important. The effectiveness of Salesforce’s evolved AI capabilities depends on accessible, reliable data, well-designed workflows, and clearly defined actions; not simply where your tickets live.
- A successful migration is an opportunity to rethink existing automation, improve knowledge management, and establish a foundation for future AI use cases.
- Migration isn’t always the answer. The right decision depends on integration complexity, business requirements, existing investments, and the outcomes you’re trying to achieve.
A support agent resolves a ticket in minutes. The customer gets an answer, the case is closed, and every metric in the help desk suggests a job well done.
What the agent couldn’t see was that the customer renews in two weeks, has an open escalation with their Customer Success Manager, and reported three product issues last month. That information was sitting in Salesforce, outside the agent’s usual workflow.
The ticket was resolved. But was the customer relationship actually better off?
It’s a distinction that matters more as organizations rethink the role of customer service. Support isn’t just about resolving individual requests anymore. It’s part of how businesses manage relationships, protect revenue, and identify opportunities to improve the customer experience. And when those responsibilities stretch across disconnected systems, even a well-functioning help desk can become a limitation.
Why Connecting Zendesk to Salesforce Often Doesn’t Solve the Problem
For organizations running Salesforce alongside Zendesk, integration is often the logical starting point. And for many, it works well. But as the business grows, so do the expectations placed on that connection. What started as basic account and contact synchronization may eventually need to support escalations, customer history, routing decisions, cross-functional workflows, and reporting.
That’s where complexity can start to outweigh convenience. And we’ve seen this show up in three ways:
- Change becomes harder than it should be. A seemingly straightforward update requires testing across multiple systems, integration dependencies, and downstream processes. Teams become more cautious about making improvements because the impact isn’t always easy to predict.
- Ownership becomes fragmented. When something breaks, responsibility can sit across internal teams, integration providers, and platform vendors. Troubleshooting takes longer, and the people closest to the business problem aren’t always the ones who can resolve it.
- The business misses opportunities to work as one. Support teams may have sophisticated tools of their own, but connecting service activity to account management, customer success, and broader Salesforce workflows requires additional design and maintenance.
None of these are inherent failures of Zendesk. They’re signs that the architecture supporting the customer relationship may no longer match how the business operates.
💡 Case in point: An on-demand delivery and logistics company
What we did: Migrated a heavily customized Zendesk environment, including hundreds of triggers and macros, to Salesforce’s service platform. The implementation included voice, email, chat and SMS case creation, a restructured knowledge base, Omni-Channel routing, and historical case migration, with a foundation for future Agentforce capabilities.
Why they moved: Supporting drivers, marketplace customers, and enterprise retail partners required increasingly complex workflows across multiple channels. The opportunity was to simplify how those interactions were managed and create a more extensible service architecture.
Five Questions That Reveal When Your Support Architecture Needs a Rethink
Not every organization needs to migrate. But a few questions can help determine whether the current setup is still serving the business.
- When someone proposes a change to a customer-facing process, how many systems and integrations need to be considered?
- If your Zendesk <> Salesforce integration fails, does your team know who owns the fix and how quickly it can be resolved?
- Are support agents regularly switching between systems to understand the full customer relationship?
- Can support activity trigger the right actions across sales, customer success, and other teams without additional manual work?
- When leadership asks how service affects retention, account health, or customer experience, can you answer confidently with the data you have?
There’s no magic number of questions that means it’s time to migrate. But if several reveal recurring friction, it’s worth examining whether the architecture is helping your teams work together or making that collaboration harder.
Your Migration Is Also an Opportunity to Build for Agentforce
AI adds another dimension to this decision.
Both Zendesk and Salesforce now offer AI-powered service capabilities. The question isn’t simply which platform has AI. It’s what you want that AI to understand, which business processes it needs to support, and what actions it should be able to take.
For organizations already operating extensively in Salesforce, Agentforce Service offers an important architectural advantage: service cases can live alongside the accounts, contacts, and other Salesforce records and workflows that inform the broader customer relationship.
That can make it easier to build service experiences that extend beyond answering questions or resolving individual tickets.
Consider an AI agent that needs to recognize an open account escalation, retrieve relevant support history, initiate an approved workflow, or hand a customer to the right person with context intact. Making that possible requires more than an AI interface. It requires reliable data access, permissions, business logic, and well-defined actions.
Data 360 can also help connect information across platforms without requiring every dataset to be migrated. For some organizations, improving their existing integrations and data architecture may be enough. For others, bringing service operations into Salesforce can simplify the number of systems involved in executing those workflows.
The important point is that migration alone doesn’t make a business AI-ready.
How you organize case categories, restructure knowledge, define escalation paths, and decide which historical data to retain will influence what your agents (human or AI) can do afterward.
It’s also why starting with a focused use case often makes more sense than attempting to automate everything at once.
💡 Case in point: An OSINT platform for physical security
What we did: Migrated Zendesk case history, automations and the knowledge base, then added Agentforce: an agentic chatbot scoped to knowledge-article questions, Einstein for Service search, conversation mining, reply recommendations, and a branded self-service community.
Why they moved: They wanted AI that answered customers from their own knowledge base and helped agents search and draft replies faster. Doing that well meant putting knowledge, case history and AI on one platform, and building for it from the start.
Most Migration Challenges Are Predictable. Plan for Them.
One of the biggest mistakes organizations make during migration is treating it as a one-for-one platform replacement.
Hundreds of Zendesk triggers and macros don’t necessarily need hundreds of equivalent Salesforce automations. Some may be redundant, some may reflect outdated processes, and others may be better addressed through Flow, Omni-Channel, or redesigned service workflows.
The goal isn’t to recreate every piece of the old system. It’s to preserve what works, improve what doesn’t, and avoid carrying unnecessary complexity into the new environment.
The cutover strategy matters just as much. There are a few approaches, each with different trade-offs:
- Grandfathering: Existing tickets remain in Zendesk while new cases open in Salesforce. This reduces the need to migrate active work immediately but requires teams to operate across two systems temporarily.
- Staged cutover: Historical and active data move through planned migration windows, with a coordinated transition to Salesforce. This can establish a clear operational switch but requires careful validation and contingency planning.
- Parallel run: Both environments operate during a defined transition period. This allows additional validation but introduces synchronization, duplication, and operational complexity that need to be managed.
Whichever approach makes sense for the business, testing, data reconciliation, agent enablement, and post-launch hypercare should be part of the plan…not afterthoughts.
And success shouldn’t be measured by whether the old system has been switched off. Look at whether agents spend less time searching for context, whether escalations move more smoothly between teams, whether reporting becomes more reliable, and whether the new architecture can support the service capabilities the business wants next.
That’s where the real return on this migration starts to show.
💡 Case in point: A mobile data collection platform
What we did: Began with a Zendesk migration and Salesforce voice implementation using Amazon Connect. The scope later expanded to include a self-service community, case management, live chat, a public knowledge base, and Jira integration for engineering escalations.
Why they moved: Their service needs extended beyond ticket management into voice, customer self-service, and engineering collaboration. Rather than continuing to add disconnected capabilities, they invested in a Salesforce foundation that could support those evolving requirements and future Agentforce use cases.
When Staying on Zendesk Makes Sense
A migration is a significant investment, and not every organization will benefit from making one. And we wouldn’t be consulting if we weren’t looking out for what’s best for your business.
If Zendesk is meeting your service requirements, your Salesforce integration is reliable and maintainable, and your teams can access the customer context they need, there may be little reason to change. Even if AI is on your roadmap, migration isn’t automatically a prerequisite.
But when service needs to become more closely connected to sales, customer success, and the broader customer lifecycle, the conversation changes. The question stops being whether Zendesk can manage your tickets. It becomes whether your current architecture can support the customer experience and operating model you’re building toward.
For organizations already invested in Salesforce, Agentforce Service may offer a more connected foundation to get there. Considering a move from Zendesk to Agentforce Service? Let’s chat about what your current setup is supporting, where it’s creating friction, and whether migration is actually the right next step.
Let's chat!
