The only Hubspot migration roadmap you will ever need.
Zendesk Data Migration Best Practices
You've decided to switch your helpdesk over to Zendesk. Your immediate next step is to create a plan - a kind of roadmap for your Zendesk data migration, from start to finish. Proper planning of your Zendesk migration will ensure that the process runs smoothly and that you make the most efficient use of your time and resources.
1
Plan Your Zendesk Data Migration
[3 min read] Read More...
2
Critical Questions to Ask Before You Migrate to Zendesk
[1 min read] Read More...
3
Prepare Zendesk for Data Migration
[1 min read] Read More...
4
Execute Zendesk Data Migration
[2 min read] Read More...
1. Plan Your Zendesk Data Migration
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.
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.
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
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:
- 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.
3. Decide what data you wish to move.
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:
- 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.
6. Determine a cut-off date.
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
2. Critical Questions to Ask Before You Migrate to Zendesk
When you are scoping your project to migrate your helpdesk over to Zendesk, there is a lot to think of. You will most likely be focused on the aspects of the migration that impact your support team and/or your end-users. Because we have the most experience with these projects, we can anticipate most of the questions that will (and should!) be asked before you embark on your "Migrate to Zendesk" project - even those you haven't or wouldn't have thought of!
These questions will be specific to your migration, so use this list as a jumping off point to a productive and comprehensive discussion with whoever will be executing your Zendesk migration.
These questions will be specific to your migration, so use this list as a jumping off point to a productive and comprehensive discussion with whoever will be executing your Zendesk migration.
- Will customer notifications be triggered during the migration?
Remember that if you use Import2, we bypass Zendesk's standard notification triggers by default during any migration. However if you've setup custom automations, this should be looked at in more detail and always, always tested!
- Will newest tickets be migrated first?
This, unfortunately, depends on your old helpdesk API. Your old helpdesk provider determines whether oldest or newest tickets are loaded first when exporting over the API, so it's best to double check with us so you can plan your cutover accordingly.
- How long will the migration take?
This, too, depends on your old helpdesk's API, as well as the amount of data you need to move. We recommend doing the free sample so you can get an accurate count of the records in your helpdesk, and we can provide you an estimate on how long it will take. Read our guide here on how to perfectly time a switch to Zendesk!
- When should I schedule the Zendesk migration to begin?
The simple answer is: as soon as you move your support team to start working in Zendesk. Your migration should start as soon as you cutover your support and stop using your old helpdesk. The actual timing will depend on how much data you have to migrate over, but this can happen in the background while your support team handles new tickets in Zendesk. You do not want to schedule your migration to start while you still have tickets coming in to your old system, so it's important to time the switch well. You can read in more detail about timing a Zendesk migration here.
- When should I allow agents in to work in Zendesk?
In most cases, agents begin using Zendesk while the migration is still in progress. This is because a seamless helpdesk switch means that your old helpdesk gets "turned off" at the moment the migration begins. So, if you receive a new ticket even before the migration is finished, your agents can work on that in Zendesk, while the migration completes in the background. The key here is to ensure your agents know the status and timing of the migration, so they are not surprised as changes and updates are happening real-time while they work.
- Do I need to import users first, before I migrate tickets to Zendesk?
Yes! A proper migration moves users over first, and then tickets after. This is because every ticket is tied to a user (i.e. the requestor), so in order for the ticket to retain this relationship to the user, the user has to be present in the database. Import2 migrations will always import the users in full first, and then begin the ticket import, to ensure all the links are kept intact.
3. Prepare Zendesk for Data Migration
Before you begin any steps to migrate data, you should think about your new Zendesk setup for optimal functionality for your support team. You'll need to complete some of these steps prior to performing your data migration, to ensure an accurate and seamless transfer. Others are up to your discretion, and what will work best for your team.
Must-haves for a Successful Migration
Tackling these items will ensure you've covered all the major components that will directly impact your Zendesk migration. The end result is a mess-free, accurate and efficient data transfer.
Must-haves for a Successful Migration
Tackling these items will ensure you've covered all the major components that will directly impact your Zendesk migration. The end result is a mess-free, accurate and efficient data transfer.
1. Agent setup
One of the first things you should do is to setup all of your support team as agents in Zendesk. Zendesk has options for what permissions you can provide to your agents, depending on the plan your are, which you can find in more detail here.
2. Adding custom fields in Zendesk
It's likely that you use custom fields to house data specific to your business. If you have those setup in your old helpdesk, you will need to recreate those in Zendesk so there is a place to import that data during the migration. In Zendesk, you can create custom fields on both users and on tickets, to capture any detail you require for your business reporting.
It's likely that you use custom fields to house data specific to your business. If you have those setup in your old helpdesk, you will need to recreate those in Zendesk so there is a place to import that data during the migration. In Zendesk, you can create custom fields on both users and on tickets, to capture any detail you require for your business reporting.
When creating your custom fields, don't forget to select the correct "type" which mirrors that in your previous helpdesk. For example, if a field is setup as a dropdown in your old helpdesk, setup that field as a dropdown with the exact same options in Zendesk.
Additional Items for Database Functionality
These items are common elements of a standard Zendesk setup. It's helpful to review which you'll find helpful for your support team and your business processes, and plan the best time to set these up (whether before or after your Zendesk data migration).
Additional Items for Database Functionality
These items are common elements of a standard Zendesk setup. It's helpful to review which you'll find helpful for your support team and your business processes, and plan the best time to set these up (whether before or after your Zendesk data migration).
1. Setup macros/saved replies
In most cases, you'll have an existing set of macros and/or saved replies from your old system that you wish to carry over into Zendesk. We recommend taking a step back at this stage, and assessing which ones are useful and which may need to be updated or excluded altogether. Then, you can move over exactly what will be best for your team to use once you start receiving tickets in Zendesk.
In most cases, you'll have an existing set of macros and/or saved replies from your old system that you wish to carry over into Zendesk. We recommend taking a step back at this stage, and assessing which ones are useful and which may need to be updated or excluded altogether. Then, you can move over exactly what will be best for your team to use once you start receiving tickets in Zendesk.
2. Setup triggers and notifications
These can be automated notifications to go out to your customers when they submit a ticket, or when your support team updates a submitted ticket, etc. You may wish to setup these automations prior to your migration, but, it is critical that you turn them off before you migrate any data (including test data!).
These can be automated notifications to go out to your customers when they submit a ticket, or when your support team updates a submitted ticket, etc. You may wish to setup these automations prior to your migration, but, it is critical that you turn them off before you migrate any data (including test data!).
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.
Thinking about your Zendesk setup prior to migration is a very helpful exercise. Even better, completing the setup before you start testing an import can help you visualize how your support team will work in the system and allow you to identify any changes you wish to make before going "live" with your new Zendesk.
Back to table of contents
Thinking about your Zendesk setup prior to migration is a very helpful exercise. Even better, completing the setup before you start testing an import can help you visualize how your support team will work in the system and allow you to identify any changes you wish to make before going "live" with your new Zendesk.
Back to table of contents
4. On the Day of Your Zendesk Data Migration: A Survival Toolkit
The day of your Zendesk migration can be stressful. It is no small feat to time and execute a swift and seamless transfer of an active helpdesk. Your agents and your customers rely on your systems to be operational, and any unexpected downtime can be a huge problem.
To alleviate as much stress as possible when you finally hit that "go" button, you can take some simple steps on the actual day you migrate:
Make yourself available.
This is the cardinal rule. You must be present while the migration is running.
Even if you've delegated the Zendesk migration task to someone else (Import2, your developer team, or a consultant), you need to be present in case they have any questions or concerns in real-time as they are working with the data. And just as if you were doing it yourself, you should check in periodically with how the data looks in your Zendesk environment. That way, if something looks "off", you can take action right away. Remember, you want to avoid any system "downtime" as much as possible, so don't wait to review and raise questions if something comes up.
Don't make any last minute changes.
It may seem obvious, but it can be tempting to want to make some last-minute tweaks. Whether it be to your helpdesk setup, your migration requirements, even something as simple as a field name update. Don't make any changes and still expect to run the migration on time! If the change is critical, then it is best to take a step back and reschedule the migration to a later date. If the change can be done post-migration - then wait until then. Just a simple change to a field name can result in 1,000's of errors in a data migration, and it is something that can easily be done after-the-fact.
Following this rule will avoid most major headaches on the day of your migration.
Remember to "turn off" your old helpdesk and route all potential sources of communication to Zendesk.
As part of your Zendesk migration project plan, you (hopefully) determined a final cutover date for your team to stop working in your old helpdesk. At the moment you press "go" on the migration, you are essentially taking a "snapshot" of your old helpdesk data and copying that over to Zendesk. You do not want any further data entry going into your old system - those additions or updates would not be reflected in the data that ends up in Zendesk.
Do what you need to do to remind your team to stop working on tickets in your old helpdesk. You can send an email reminder, have a calendar event or even deactivate access, to ensure no one accidentally logs in and makes any changes. This will ensure you do not end up with data in "limbo" and subsequently deal with the headache of figuring out what data was missed during the migration.
Use the list you compiled during your project planning of all the potential sources of customer communication and double-check those are all being routed into Zendesk. This includes any website form which creates a ticket, chatbots, help center links, and so on. You do not want any tickets being created in your old system after the migration starts.
Make a personal plan for how to handle issues.
You don't want to be taken off guard if your migration results in more errors than you anticipated, or if you see data that looks "off". Instead of panicking or rushing to pause or cancel the migration, decide how you want to handle any issues that arise.
For example, come up with a strategy for dealing with errors. Will you resolve them in real-time, or will you wait until the migration is complete to see a full list and tackle it then? Will you enlist the help of your support team to resolve them post-migration?
Or, what if you see data which looks inaccurate which will critically impact your company's ability to do business? Will you pull the plug on the migration and start again from scratch when you've had a chance to assess the issues? Or, will you make an attempt to fix post-migration?
Ideally, there will be little to do on the day of the migration. You've planned and prepped, tested and validated. The final, full migration to Zendesk should reflect that preparation and should result in exactly what you expected. In the event things come up (and they do!), just breathe and remember to review the above to survive the day-of.
Back to table of contents
To alleviate as much stress as possible when you finally hit that "go" button, you can take some simple steps on the actual day you migrate:
Make yourself available.
This is the cardinal rule. You must be present while the migration is running.
Even if you've delegated the Zendesk migration task to someone else (Import2, your developer team, or a consultant), you need to be present in case they have any questions or concerns in real-time as they are working with the data. And just as if you were doing it yourself, you should check in periodically with how the data looks in your Zendesk environment. That way, if something looks "off", you can take action right away. Remember, you want to avoid any system "downtime" as much as possible, so don't wait to review and raise questions if something comes up.
Don't make any last minute changes.
It may seem obvious, but it can be tempting to want to make some last-minute tweaks. Whether it be to your helpdesk setup, your migration requirements, even something as simple as a field name update. Don't make any changes and still expect to run the migration on time! If the change is critical, then it is best to take a step back and reschedule the migration to a later date. If the change can be done post-migration - then wait until then. Just a simple change to a field name can result in 1,000's of errors in a data migration, and it is something that can easily be done after-the-fact.
Following this rule will avoid most major headaches on the day of your migration.
Remember to "turn off" your old helpdesk and route all potential sources of communication to Zendesk.
As part of your Zendesk migration project plan, you (hopefully) determined a final cutover date for your team to stop working in your old helpdesk. At the moment you press "go" on the migration, you are essentially taking a "snapshot" of your old helpdesk data and copying that over to Zendesk. You do not want any further data entry going into your old system - those additions or updates would not be reflected in the data that ends up in Zendesk.
Do what you need to do to remind your team to stop working on tickets in your old helpdesk. You can send an email reminder, have a calendar event or even deactivate access, to ensure no one accidentally logs in and makes any changes. This will ensure you do not end up with data in "limbo" and subsequently deal with the headache of figuring out what data was missed during the migration.
Use the list you compiled during your project planning of all the potential sources of customer communication and double-check those are all being routed into Zendesk. This includes any website form which creates a ticket, chatbots, help center links, and so on. You do not want any tickets being created in your old system after the migration starts.
Make a personal plan for how to handle issues.
You don't want to be taken off guard if your migration results in more errors than you anticipated, or if you see data that looks "off". Instead of panicking or rushing to pause or cancel the migration, decide how you want to handle any issues that arise.
For example, come up with a strategy for dealing with errors. Will you resolve them in real-time, or will you wait until the migration is complete to see a full list and tackle it then? Will you enlist the help of your support team to resolve them post-migration?
Or, what if you see data which looks inaccurate which will critically impact your company's ability to do business? Will you pull the plug on the migration and start again from scratch when you've had a chance to assess the issues? Or, will you make an attempt to fix post-migration?
Ideally, there will be little to do on the day of the migration. You've planned and prepped, tested and validated. The final, full migration to Zendesk should reflect that preparation and should result in exactly what you expected. In the event things come up (and they do!), just breathe and remember to review the above to survive the day-of.
Back to table of contents