Fra Salesforce
til Zendesk
Behold Salesforce som CRM – flyt kundeservicen til en platform, agenterne kan bruge
It is rarely an either-or
Salesforce Service Cloud is a powerful platform, but it is built to be configured by specialists. That is also the usual reason companies start looking elsewhere: every change needs a consultant, agents find the interface heavy, and months pass between a request and a change.
The important thing to understand is that a switch rarely means leaving Salesforce. In most cases Salesforce stays as the CRM with accounts, opportunities and sales data, while customer service moves to Zendesk – and the two systems talk to each other.
That makes the migration more layered than a classic helpdesk move. It isn't only about moving cases, but about drawing a clear line about where truth lives, and building an integration that holds that line.
Why move customer service out of Salesforce?
The patterns we see in companies that make the call
Changes take too long
A new field, queue or automation typically has to go through a development cycle. In Zendesk an administrator can do most of it themselves, the same day.
The agent experience is heavy
Service Cloud is built broad and deep, and you feel it day to day. Fewer clicks per ticket isn't cosmetics – it is minutes saved on every single contact.
Omnichannel costs extra
Chat, messaging, voice and self-service often require several products and licences. Zendesk Suite bundles the channels into one package and one ticket history.
Total cost of ownership
Licences, consultant hours and internal administration stack up. The maths often looks different once you include running the thing, not just the list price.
What can be migrated?
How Service Cloud objects translate into Zendesk
Cases with feed and files
Tickets with comments and attachments
The Case Number is stored in a field so customers and other systems can still look it up.
Accounts and Contacts
Organizations and Users
Here you decide which system owns customer data going forward. Our usual recommendation: Salesforce owns, Zendesk reads.
Knowledge Articles
Guide / Help Center
Article types and data categories map to categories and sections. Usually where the biggest clean-up happens.
Queues and Assignment Rules
Groups, views and triggers
Queues become groups and views. Assignment rules become triggers or omnichannel routing.
Entitlements and Milestones
SLA policies
Zendesk's SLA model is simpler. Complex milestone logic usually has to be deliberately simplified rather than copied.
Apex, Flows and Process Builder
Triggers, automations, webhooks and apps
Coded logic does not translate automatically. We review what is still needed – in our experience, far from all of it.
How a migration works
Five phases where you know exactly what happens when
Mapping
We review your current setup: channels, volume, workflows, integrations and the habits that aren't written down anywhere.
Designing the Zendesk setup
We design fields, forms, groups, SLAs and automations around your processes – not around a standard template.
Test migration
We move a subset of the data first so you can see and approve the result before we touch production.
Full migration and go-live
We run the full move, switch the channels over and are on hand the day you go live.
Training and adjustment
The team is trained before go-live, and we adjust views, macros and rules in the weeks after, once daily use shows what is missing.
What usually causes trouble
What makes Salesforce migrations different
Decide the source of truth first
If both Zendesk and Salesforce may edit customer data, conflicts appear within weeks. Decide the sync direction before you build anything.
Reporting and management overview
Someone has built dashboards that are used in management meetings. They have to be recreated in Explore – and you need to agree who owns them going forward.
The Experience Cloud portal
If you run a customer portal with login, it must be replaced by a Help Center with user login, or integrated. That is its own track in the project, not a detail.
Internal resistance is real
Salesforce usually has strong internal advocates. A switch only works if service, sales and IT decide together – not when it is decided over someone's head.
Why migrate with Available?
We have moved customer service departments between systems long enough to know that data is rarely what derails a project. It is the decisions nobody made along the way: who owns the customer, what should we stop doing, what do we do with the 400 macros nobody uses.
So we spend as much time on your processes and your team as on the move itself. A migration is the best opportunity you will get to clean up – and the worst one to waste copying old mess into a new system.
Connecting cables and hearts.
Frequently asked questions
Explore more
Related pages that can take you further
Considering moving service out of Salesforce?
We know both platforms and will tell you honestly what a switch takes – and what you should keep in Salesforce.
Contact usSee all migrations to Zendesk