Top 5 Considerations for Migrating from Desk.com to Service Cloud
The Desk.com sunset is less than a year away and if you don’t already have a plan to move to Service Cloud, there’s no better time to start than now.
The good news is that Salesforce and Desk have a lot of resources to help your move including Trailhead modules, FAQs, and other services that will help you and your team migrate.
It’s worth knowing that there are some pitfalls and considerations unique to the Desk.com to Service Cloud migration that won’t be obvious in those resources. For instance, these Best Practices are for migrating to Salesforce CRM, not Service Cloud specifically, but the advice is sound from an overall planning and project management perspective.
To connect the dots on all this, we’ve outlined the top five considerations when migrating from Desk.com to Service Cloud.
1. Data migration from Desk to Service Cloud
In our experience, this can be the most time-consuming and painful part of the migration, so we’re tackling it at the number one spot. There are really two ways it can go.
If you’re creating a brand-new Salesforce instance that has no existing data, then the process is fairly straightforward. You’ll be able to use the Desk Migration Wizard in Salesforce to move Desk data over, including any Knowledge articles.
If you have an existing Salesforce system with existing data, then it’s not as straightforward, but still manageable. You’ll have to use Data Loader and if the Customers in Desk need to move over to existing Accounts in Salesforce, that’s harder still.
Some things to keep in mind:
In Desk, Customers and Cases are king. Customers get associated with Companies (more on that in a sec), but Companies aren’t the parent object.
In Salesforce, Accounts (named Companies in Desk) is the parent object, with Cases and Contacts as child objects. That means you have to first figure out if there are any Companies in Desk that don’t exist as Accounts in Salesforce, create new ones, and associate the Customers and Cases you’re going to import to those Accounts. In other words, lots of VLOOKUPs.
So one of your biggest worries is whether or not Companies were reliably used in Desk. To determine this you can ask the following:
Do the Company names in Desk match existing Account names in Salesforce exactly?
Did the support team use Companies at all? They may not have for every Customer, because any email-to-cases that came into Desk likely had the Company logged as the customer’s email provider; they would have had to manually change the Company on many cases.
Next up: how much legacy data do you really need to move? It’s tempting to move all of it, or go back several years at least. If you get to use the Data Migration Wizard, that may not be so bad, but if you have an existing Salesforce org, you’ll be working with large Excel/CSV files.
There are limits on how many rows you can have in one file, and how much processing your laptop can handle. A few thousand cases aren’t too bad, but tens or hundreds of thousands can cause the number of hours you spend prepping and cleaning those files to increase exponentially.
Consider how many of your customers come back and log multiple cases, and how far back in your system you really need to go. It’s most likely that 6 months to a year of legacy data is enough.
Desk.com is going to send you CSV files with all of your old data; you can always store those in a secure place, for the rare instance where you’d need to research a case from 3 years ago.
Just one more thing about data -- be sure to double-check your data storage in Salesforce. If you’re at 80% on your data storage and are planning to import tens of thousands of contacts, companies, and cases, avoid any nasty surprises now.
Each contact or account record is ~ 2K, and cases can take up more than that when you consider any activity/email messages associated with the case. Check your storage limit, Salesforce will let you exceed it, but they will find out and bill you for it. Heads up, it can be quite costly.
2. Begin at the end
Think about your deployment plan and work backward from there. While you’re at it, figure out when your Desk contract ends in relation to your Service Cloud deployment plan.
Although it’s most cost-effective to end your Desk contract on a Friday and start/go-live with Service Cloud the following Monday, that’s also the most stressful and risky way to deploy. It’s good to determine what timelines will work best for the success of your Support teams.
We suggest moving to Service Cloud at least a couple of weeks before your Desk.com contract ends.
That way, you have a built-in backup plan if your Service Cloud deployment doesn’t go as planned, simply go back to using Desk temporarily until the kinks are worked out.
This prevents any downtime that would affect your customers and diminishes the stress of the change. Another benefit of this timing is that your Support team can finish out cases in Desk while creating any new ones in Service Cloud.
3. Prioritize what's essential
Make sure that the case channels customers most often use to connect to Desk are prioritized, and any cool but not immediately necessary Service Cloud functionality gets second billing.
You want to get to what Product Managers refer to as an MVP, or minimally viable product.
Murphy’s Law mandates that the worst thing happens at the worst possible time, and the worst possible time is right before go-live. If you need to push some functionality until after go-live, it helps to have already identified the second-tier functions and made the team aware that those items may have to wait in order to focus on the must-haves.
4. Support team adoption
There are a couple of project planning items you’ll have to do for a successful implementation anyway, and getting the team’s help on those will familiarize them with the system while providing you with invaluable insight.
Have a testing plan and involve the support team in testing. They’ll get to experience the new functionality and interface quickly, while identifying potential issues that you won’t anticipate.
Use the testing results to iterate, then go back to the team and test the improvements. Now you’re building the Support team’s trust in the new system, and that improves user adoption and ultimately, their ability to service the customers.
5. Leverage your Salesforce Account Manager
You’re moving from one Salesforce product to another, and your Account Manager is just as invested in your company’s success as you are. If you’re having problems getting the right help, get some time with them to come up with a strategy. They’re there to help!
That’s it! (I know, it’s a lot.) You have a lot of planning to do and meetings to schedule, but hopefully, this advice can help you anticipate and avoid as many speed bumps as possible.
We’re here to help you cross the finish line and happy to chat with you about how we can help your team be successful. Get in touch with us here to start the conversation.
Kim started with Salesforce first as a user in 2008, then later as a manager for a SaaS company in Cary, NC. That experience led to a love of the platform and a career change to full-time Salesforce administrator. Kim has two decades of experience managing projects and teams, loves the Blue Devils (AB ‘87), and one time she had to kill a snake by shooting it (it’s a long story). Connect with Kim on LinkedIn or send her an email.