Jira Service Management 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 Management, 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 seamless data migration. So, grab a pen and a notebook, and without any further delay, let's dive into the Jira Service Management 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 Management. This way, you can have a full picture of what to expect from the transfer. So, these records are:

CC users (migrate CC users into a custom field instead)
Groups
Inline images

We understand that some organizations would really benefit if they could have some of these records migrated to Jira Service Management 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.

Note: When importing your Knowledge base into Jira Service Management, its dates will change from the original ones to the dates of data migration itself.

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, 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 Management 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. 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 Management, 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.

2. 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 Management, simply go to Settings > Issues > Fields(Custom fields) > Create custom fields.

how to create custom fields in jira service desk

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 Management has this thing called the projects, so make sure your custom fields are added to the correct project screen.

3. In Jira Service Management, 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.

4. 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 Management 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 Management unique will help you avoid any unexpected surprises. So, Jira Service Management 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.
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.
By default, you cannot move organizations to Jira Service Management. However, in a custom migration, we can help you move organizations to a custom field of the ticket, which will then make it possible to automatically associate all customer accounts with organizations. If you're interested, reach out to our agents and ask for a custom migration.
Do not deactivate end-users because we will not be able to migrate their case.

An important note: Keep in mind that only one Project of yours (the one you choose when connecting Jira Service Management to Migration Wizard) can be transferred during one data migration process.

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. 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 Management. 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 Management

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.

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. 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 Management, 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

We understand that there may be several reasons for data migration. Some are simply looking for an upgrade, the others just moving separate teams. No matter what drives you, we always advise running the Full Data Migration on a day with the smallest amount of incoming requests. If needed, you can still work on your source help desk during the transfer, however, the records created or updated after the start of the Full Data Migration will not appear in Jira Service Management automatically. If you don't want to lose that data, you can always opt for delta migration.

When it comes to the Full Data Migration, you don’t have to sit in front of the computer the whole time – you can just check on the transfer from time to time or ask your agents to help you out. Our team will keep a close eye on the process of migration and if something seems out of place - we’ll contact you right away.

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.

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 Management. 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. Speaking about time, if you have a specific time and day in mind, you can schedule the migration to run automatically based on that timing.
Additionally, you'll have to agree to the short checklist that we provide after the payment. That is needed to ensure you're completely ready for the Jira Service Management import. To do so, click on the link to open the checklist, go through each point, and if everything looks good, put a check into the corresponding box.

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. 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 Management. 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 Management, click on the chat icon below. Our team is always ready to help.

More data migration checklists here.