Jira Service Desk Data Migration Checklist

The data migration is certainly far from being easy. Even considering all the benefits it can bring to the table, it’s not surprising that many large and small businesses tend to put it off. The process might be complicated, time-consuming, and pricey. Truly, it was like that before automated solutions, like Help Desk Migration Service, appeared on the market. Now, you can half the average time and effort needed for a transfer with no data migration expertise.

Sounds good? Let's top it off with a detailed data import checklist, exclusive to Jira Service Desk, covering every nook and cranny of the migration process. And now, it sounds perfect. If you follow it precisely, you're getting a few steps closer to the seamless data migration. So, grab a pen and a notebook, and without any further delay, let's dive into the Jira Service Desk data migration plan.

Each platform is unique, which allows us to migrate different entities. Before we proceed further, we find it essential to state the records that cannot be migrated over to Jira Service Desk. This way, you can have a full picture of what to expect from the transfer. So, these records are:

Private notes (migrate as public notes or into a multi-text custom field instead)
CC users (migrate CC users into a custom field instead)
Request types
The connection between the company and contact
Groups
Inline images

We understand that some organizations would really benefit if they could have some of these records migrated to Jira Service Desk anyway. For such cases, we offer an opportunity for customized migration. Simply contact our team in advance to discuss the peculiarities of the personalized transfer. One of our agents will assist you regarding any questions you may have on the topic.

Before You Set up the Migration

Data migration is full of challenges, however, you can easily avoid them if you know some insights (that you're about to read). In this section, we'll mention some of the things that could help you to cut corners and speed things up while still preserving the data integrity. Without further ado, let's start.

1. Decide on a date

It may sound obvious, but you can't just open the calendar and pick the first day you lay your eyes on. There are quite a few factors you have to consider, and believe us, combining all of them to fit a single perfect day, certainly isn't a 5-minute decision.

First of all, it has to be far enough, so you can thoroughly prepare for the transfer (by starting to close tickets and filter your data, for instance).
Secondly, starting from the cut-off date, you should work solely on Jira Service Desk. No changes or inputs should go to your current help desk. That's quite essential for the success of the migration.
Last but not least, during the cut-off date, there will be a downtime. And depending on the number of records you have to transfer, the downtime may last up to 24-hours. Thus, try to aim for the day with the smallest amount of help-desk related work.

We advise you to take the time when deciding on this one to minimize the overall impact and not rush things up when it comes to data migration.

2. Inform your team

Right after the decision about the data migration has been made and the cut-off date has been set, gather a company-wide meeting and talk through your plans. It's important to give everyone in your office a heads-up about the significant change that will cause a 180-degree turn to their normal workload. Make sure to inform your agents first, so they can start closing tickets before the cut-off date.

Instead of trying to handle everything single-handedly, you can delegate certain responsibilities. It can be anything, starting from data filtering to examining the data after the Full Data Migration. Distributing things is vital for overall accuracy and better productivity.

A tip from the HDM team: As we've mentioned above, starting from the cut-off date, no data should go into your old help desk. Therefore, to prevent someone from doing it accidentally, set a reminder a day before. It can be an email, a calendar event, or whatever works for you the best.

Similarly, you can also inform your clients about the big changes on your blog (if you have one). That will, for sure, help them understand better why there is downtime in the first place.

3. Clean up

If you've been using your current help desk for a while now, your data is probably not the cleanest. It can be full of duplicates, unassigned ticket conversations, outdated profiles, irrelevant entries, and invalid emails. Sounds like a lot of clatter. Thus, we recommend you to take the time and look through your current data and get rid of unnecessary records. This way, you will end up with an organized service desk and a thicker wallet, since HDM service charges per migrated record.

A tip from the HDM team: Ask your agents who deal with the data daily to separate the essential items and decide what to delete. They certainly know what can and should be left out, especially if you haven't used certain records for more than a year. For such cases, consider using the 'Last modified' filter if your service desk has one, it will cut the time required for the cleaning process in half.

However, we fully understand that some of you may not have the extra time or human resources on hand. If that's a case, you can easily opt for automated filtering. It will cost some extra but will save your hours and hours of manual work. Simply, drop us a line in advance and tell us the criteria you want your data to be filtered with. That's it. You get to enjoy clean data as we will take that filtering process upon our shoulders.

4. Prepare Jira Service Desk for the import

Before the migration even starts, you have to perform certain actions to ensure that the transfer will go as seamlessly as possible. We suggest you pay attention to the following:

1. Create corresponding custom fields. That should be done to help you locate all the data after the Full Data Migration in no time. If you do this step properly, you will know exactly where to look for each record. Sounds convenient? But at first, you should recreate the identical types of custom fields to the ones you currently have manually. This is not a timely process. To do so in Jira Service Desk, simply go to Settings > Issues > Fields(Custom fields) > Create custom fields.

Set the Resolution field on the mapping, otherwise, all the migrated cases will be unresolved. You can map the Status field to Status and Resolution fields twice. Also, Jira Service desk has this thing called the projects, so make sure your custom fields are added to the correct project screen.

2. In Jira Service Desk, you can set the size of attachments users can add to requests. We recommend you go to settings and increase the size limit to import all the attachments.

3. Contacts from your current service desk can only be migrated if you enable the 'Public sign-up' setting.

Make sure you have admin rights to both your accounts in the source platform and Jira Service Desk for migration to go through.

5. Consider the peculiarities and limitations

Studying the main features of your new platform is equally important as any of the steps described here. Knowing what makes Jira Service Desk unique will help you avoid any unexpected surprises. So, Jira Service Desk has the following peculiarities:

There are two types of desks in Jira – Classic and Next-gen (basically more advanced version of classic one). Currently, the migration only to the Classic projects is available. But, you can still migrate your data to the Next-gen project. Learn how on our blog.
All users have to be added to the project of choice and have their emails visible to everyone. The users don’t migrate automatically to Jira Service Desk, you have to add them manually. It is a multiple-step process, and we strongly advise you to check out the article with visual materials explaining how to do it.
Set 'Request type' for all the migrated cases. Only this way, after resetting password in Jira Service Desk, customers will be able to see their cases after the migration.
By default, you can only set one issue type per migration to be applied to all issues. Unfortunately, you can't specify multiple issue types because each issue type has its own workflow, and therefore custom fields. As a solution, you can divide your migration into several ones, and each time migrate tickets of only one ticket type. More details in our Knowledge Base.
Private notes cannot be migrated to Jira. You can either move them as public ones or to a multi-text custom field. The same goes for CC users, which can be migrated to a custom field.
Do not deactivate end-users because we will not be able to migrate their case.

6. Contact HDM team

After you've completed all the previous steps, feel free to reach out to our team to discuss the definitive details about the upcoming migration. We will also coordinate your further actions, ensure that everything goes smoothly, and advise when any questions arise.

It's also the perfect timing to discuss the possible customization, including migrating private notes as public ones or into a multi-text custom field, CC users into a custom field, and setting default agents. Simply drop us a line and rest assured that all your requests will be done just perfectly.

You’re Almost Ready

Initiate the Demo Migration

Instead of you jumping right into the Full Data Migration, we offer a free trial. During the demo, we take a small portion of data from your current help desk and move it to a target platform, in this case, Jira Service Desk. The process should take no more than 5 minutes but will allow you to have a sneak-peek into how things will look like after the Full Data Migration.

The process of demo migration can be repeated multiple times, entirely free of charge. We strongly advise not to skip this step and make full use of it.

After the Demo Migration

1. Carefully check the results in Jira Service Desk

As we've mentioned above, the demo practically mirrors the way things will go during the actual migration. If something isn't right, it will be the same with Full Data Migration. Thus, you should check if everything got transferred as planned. The amount of 20 tickets is small, so it shouldn't take much time to check each of them.

Due to the platform peculiarities, you have to manually upload a JSON file to your Jira Service Desk account. Take a look at the article to learn how to do it in the right way.

Please, check if:

all comments got migrated and if the authors of the comments are the same
the tickets are assigned to the correct agents
all the custom fields got migrated
the customers and companies are migrated correctly
the attachments and labels are migrated

2. Delete the migrated tickets

With Jira Service Desk, our service cannot directly access your account and automatically delete the test portion of data for you. You will have to manually remove it yourself. Do not skip this step if you don't want to end up with a pile of duplicates after the Full Data Migration.

3. Get a custom demo

If you have some tickets with more replies, attachments, or notes than your usual ones and want to see how they migrate over to Jira Service Desk, feel free to request a custom demo - we’ll transfer the specific ticket IDs that you want. Just contact our team before you're planning a demo, and we'll arrange one for you.

During the Full Data Migration

1. Keep in mind the basics

You're almost ready to initiate the migration. However, double-proof that you'll be running the Full Data Migration on a day with the smallest amount of new requests to prevent any interference in the process.

Our team will constantly monitor everything, your presence may help a lot. You aren't required to just sit in front of the computer screen all day - just check on the transfer from time to time, or ask your team members to do so. As soon as something seems a bit off – we'll inform you in no time. Our agents will do everything to either resolve the issue instantly or coordinate your further actions.

2. Don't make any last-minute changes

Unless you want to deal with major headaches trying to resolve numerous problems, don't make any last-minute changes. While the Full Data Migration is running, all you're left to do is monitor the process from time to time. If something seems out of place, DO NOT try to resolve the issue by yourself. Inform us about the problem and let professionals handle it. Even the smallest alterations can cause a thousand failures to happen, and considering all the efforts put into the preparation, it wouldn't be the best choice to make. As we've learned from our experience, most of the things can wait until after the Full Data Migration is complete.

Please, double-check that your source help desk is completely turned off, and no new data is coming in to prevent any mishaps.

3. Start Full Data Migration

After you've checked everything and feel confident about the results of demo migration, press 'Start' to initiate the Full Data Migration. As of this moment, all records will start to migrate one by one to the Jira Service Desk. The time it will take depends on the amount of data you're migrating, which is precisely why we stressed the importance of cleaning the old desk.

Keep in mind that the migration will not begin until the payment is confirmed. The confirmation process may take some time, so it's recommended to pay in advance, especially if you have a specific time you want to start at.

After the Import is Done

1. Check once again

You're just a few steps away from fully enjoying your new platform. But first, inspect if everything migrated accordingly. If no issues appeared after the demo migration, most likely, things went smooth here as well. However, just to double proof – go through your data and examine everything. Ask your agents for help with this one to cut the time. You shouldn't only check the number of different entities but make sure they are readable and in place.

Note: You don't have to inspect everything right after the Full Data Migration has ended, but don't forget to download the file with the results as it can disappear seven days after the import.

A proper inspection right after the Full Data Migration leaves a place for free correction on our side if noticed right away (within five days after the migration date). If you do encounter an issue, drop us a line - our agents will be more than welcome to help.

2. Update your new platform

At this point, all you left to do is just a few final touches. Since Jira Service Desk doesn't allow to associate companies with contacts automatically, you'll have to do it manually. The same goes for setting a request type for cases. Additionally, if you migrated Knowledge Base articles, don't forget to manually update internal links. Make sure not to skip this, as, without the request type, customers will not be able to view all request details.

Last but not least, re-forward your emails to Jira.

In general, try to get used to a new platform. After using another service desk, things can seem weird at first, but you're set to success after you figure everything out.

Wrapping It Up

And there you have it – a data import checklist to Jira Service Desk. If you follow everything precisely, your migration experience will be smooth and painless.

If something wasn't clear enough or you would like to talk to a specialist about the peculiarities of your data import to Jira Service Desk, click on the chat icon below. Our team is always ready to help.

More data migration checklists here.