Before you dive into any of the details of mapping data, setting up your reporting, integrations or any other functions of your new helpdesk, it's important to get a handle on the 30,000 foot view of what your migration project entails. These key components will be absolutely necessary to those involved in executing the migration, and it's best to have the answers well thought through and documented before you begin.
1. Loop in the right people.
Your helpdesk is not used by just one person. You want to be sure that you have invited those that will be most impacted by the decisions and the results involved from migrating the data to be a part of the process. This doesn't mean that the CEO needs to be on every status call or validating test import results. What it does mean is that your customer support manager and your support team are made aware of the timing of the migration, when testing will happen which may impact the reports they view, and so on.
Not only will their involvement ensure everything goes smoothly, but it will help distribute the responsibility of validating the import results. If you can, allocate the review of import test runs to those most familiar with the data. For example, you can have each agent check tickets assigned to them. This will significantly increase the confidence and accuracy of the migration results. 2. Determine the method of migration.
You're here because you are considering a third-party service, like Import2, for your Zendesk data migration
(a good choice!) When looking at your options, you should be aware of the advantages and disadvantages of those before you commit, as well as how they fit with the resources (time and expense) you can allocate to the project.
In a nutshell, you will decide if you want to:
3. Decide what data you wish to move.
- Use Zendesk API. If you have developer resources at your disposal, you can use Zendesk API to import data into your new helpdesk. Before you look into this option, be sure that you are able to extract data from your old helpdesk as well - either by API or CSV.
- Hire a Zendesk consultant. There are plentiful choices out there for Zendesk consulting services, who essentially work as a project manager for your helpdesk migration - albeit this can be a costly and slow-moving option.
- Use Import2 to automate the technical aspects of the migration for you. We work with you to scope the requirements of your project - but, unlike a consultant, Import2 utilizes our technology to automate the tedious steps of mapping fields, exporting and importing the data. This means the process moves swiftly, and you can offload all of the heavy-lifting of the migration.
This means carefully considering what data you want to keep, and what data (if any) you will exclude. A successful migration does not necessarily mean transferring every piece of data. In fact, a migration to a new helpdesk is the perfect time to take stock of your current data and assess what is truly useful for your support team.
Practically speaking, it is typically more expensive (and more labor intensive to review and validate) to move more data. So, if you don't need large chunks of data for your business processes or reporting moving forward, decide now and leave it behind.For example, if you received a large amount of spam or other non-customer correspondence in your old helpdesk platform, identify that and exclude it from the migration. 4. Prep your data.
You know the phrase - messy data in, messy data out. If you don't take care to clean-up your data as best as possible prior to the migration, you will still end up with a messy database at the end - just in a shiny new package. If you have years of bad data collecting in your old system, it may not be possible to get it perfect. However, you can still try to tackle any major items before you make the move, such as:
- Invalid emails
- Unassigned ticket conversations
- Duplicate contacts and/or companies
- Purging contacts that have no ticket history
There are many approaches to cleaning up data, and you will have to decide what makes sense for your business and the current state of your helpdesk. The end goal should be to achieve a set of data that you feel comfortable moving over and using in Zendesk.
In the case that you are limited in what you can tidy up, but you still want to "cleanse" your database before you make the switch - you can think about what filtering may be possible to get to your desired end result. If you have specific criteria that can be applied to filter out the data you wish to exclude, communicate this to your migration partner so it can be applied during the transfer! 5. Prep your new Zendesk environment.
There are some basics you'll want to have setup
before you begin any practical steps to migrating your data. You should ensure you have:
6. Determine a cut-off date.
- Setup any custom fields you need to accommodate your old data
- Added your agents
- Setup any macros/saved replies you'll need to use once you start receiving tickets in Zendesk.
- Turned off any triggers, notifications or other automations you may have already setup in Zendesk. If you are using Import2 for your data migration, the standard Zendesk notification triggers are bypassed during the migration. However, if you've setup any yourself, it's best to double check and disable those to be safe. This ensures that no unwanted customer notifications go out during the testing or actual migration.
This may be the most critical step of your migration plan. It is imperative to time your switch to Zendesk accurately, and in a way which accommodates both your team and your customers.
Your team should start working only
in Zendesk as soon as the migration starts. There should be no data entry into your old helpdesk system, to ensure that you are migrating the most up to date data, and that you won't lose any updates that your team may enter after the fact. A cut-off date will allow you a clean, accurate and timely transfer.
From the customer-side, you'll want to ensure that all new customer communication is received in Zendesk. Check that you have audited all potential sources of incoming communication, and have them routed to Zendesk at the time of the switch. Back to table of contents