Whether you need to move to Jira Service Desk to scale or maybe you ran out of features in your old solution, the process isn’t fas nor easy. Migration as-is is a complex process that even if you wanted to rush, you can’t. It takes days to prepare and even more time to move things correctly. However, it doesn’t mean that you cannot speed-up things that would allow you to half the average time.
That’s right, today we are taking things a little deeper as we will not only talk about how you can move your stuff but what challenges might await you and how you can tackle them. We will also show you how you should prepare your data for the move. So, without any further delay, let’s dive into the Jira migration plan.
The Difficulties of Migration - In Brief
Now before we begin with challenges, we must first talk about the act of migration and why things are so difficult at times. So, generally speaking, migration is a process where data is being moved between two systems, the source, and the target. Usually, both of these systems are different, despite the fact that they are able to do the same things.
How they differ usually cannot be traced on the surface but rather on the inside. Each tool is made using different coding techniques, languages, and platforms. The reason why they are made so differently is code originality. That’s right, software developers, just like artists, musicians, and other creatives, must follow originality guides. Their work must be 100% unique. Otherwise, they cannot patent it, and other companies might take legal action against them for stealing work.
Another reason why tools differ from one another is that each one of them has unique features that require different types of file structuring, data processing, among other things. All disables us, users, to freely move things from one tool to another.
Core Challenges of Migration Projects
Now that we’ve learned why it can be hard to migrate things to another tool, let’s take a look at the core challenges of most migration projects. These usually stem from both, technical and business side of things so instead of mashing them together, we will divide them into two sub-categories for reading clarity.
Let’s start with technical issues. As we already mentioned, tools are different from the inside and cannot move data freely but that is only half of the story. Sometimes both systems can import and export data in common file formats such as XML and CSV. Some of you might wonder where the trouble lies then? The answer is simple, file formatting.
If your solution dishes out files using a structure that your target platforms understand but misinterpret, you will get a lot of headaches. What we mean is that your target might assign certain fields in the wrong boxes which will result in data mix up. This is further worsened if your current tool pushes un-editable files.
Another issue that you are most likely to encounter is that even if both files are of the same file structure and can be read, you might find functionality that is not present in the source tool meaning that data cannot be migrated (easily at least). You will either need to recreate the same data in the target solution manually or convert the values into something that you can fit on the target. Either way, this isn’t optimal and will require a lot of prep work which leads us to the next section.
Preparation work is simply essential. If you neglect to do it, you will end up having a ton of troubles. And this is where the first business challenge arrives. You need to do prep work which can be costly as you need to take people away from their usual duties and ask them to gather data, follow deadlines, finish work in advance, among other things.
This isn’t the only issue. You will also need to stop work on your current service desk platform meaning work won’t be done at all. Downtime can be costly, especially if you factor in the fact that a significant portion of your business will be just “waiting”. For small companies that rely on incremental income, this is a death sentence whereas bigger ones will lose a lot.
Last but not certainly not least, depending on the size of the company, the migration process can be lengthy as you need to do data cleansing. Deciding what is useful and what is not in a fast and effective manner is virtually impossible as it takes a lot of decision making and a lot of persuasion of the board. All this leads to a huge loss of time and time is money.
How to Prepare to Migrate to Jira Service Desk
Although there are a ton of challenges, not all are grim and dark and in many ways, a shift in tools can breed more benefits than drawbacks. There are many ways you can cut corners, speed up things, among other things. Let’s take a look at some of the things you can do to accelerate your migration all while not losing any accuracy and data integrity.
Communicate Your Intents
This is the most important step in the entire migration process as not telling your people and customers (if your current solution helps with them) about the migration can result in a lot of issues, including a damaged reputation. It is vital that all parties that are involved in the support platform know about the upcoming changes. This will give them the ability to close their tickets faster and adjust their workload accordingly. Furthermore, this will also help your customers understand why there is downtime in the first place.
Settle on a Budget
Every migration project is an expense so creating a budget is only natural to the success of the project. Typically, migration is not very expensive, provided that you’ve planned the entire process correctly. If not, you will go overboard. We suggest that you count how many man-hours it would take to get things done prior to the migration process and then add some to safeguard yourself from unexpected hiccups.
Evaluate Your Data
This process involves a myriad of small tasks that can be divided into two categories, data size analysis, and data complexity analysis. Knowing how big your records are and how complex their structure is will allow you to learn how much storage you’ll need and whether you can compress or optimize certain records.
Clean Your Data
This process can be both lengthy and short. How? It depends on how much data you have and whether you’ve been doing regular data audits. Cleaning your record base from duplicates, outdated profiles, or irrelevant entries will allow you to have a cleaner start on the new solution, as well as you’ll have to move less data back and forth which will result in things being faster.
Assemble a Team
This process is critical for the success of the preparation phase. The general rule is that when everyone is responsible, no one is responsible. By having a board of experts, you increase the success rate almost double. That's because each expert can track what division is doing what and how much it takes to complete the goals. Another benefit of this approach is that you’ll have more accurate progress reports which will allow you to make more accurate decisions.
Prepare the Source & Target
Now each tool is unique and you will certainly need to do some configuring. This is unavoidable and you will certainly not find a tool that can do this automatically. Generally, it is recommended that you turn off all incoming/outcoming notifications and automations. This will ensure that data won’t be updated during the migration and that no errors will occur afterward. Not turning stuff off so will almost certainly result in you doing a Delta Migration (when you move the updated records).
When Do You Need a Partner?
There are times when you have so much stuff on your hand that you simply don’t know whether you can handle it on your own or not.
To help you identify this, see the following list of criteria:
- If you have a limited store of internal resources
- Need assistance if you have questions that are outside of platform-holder jurisdiction (data evaluation, migration complexity, project management, planning, etc.)
- Want to migrate complex custom apps and extensions
- Need to follow unique security and compliance needs
- Want to move a massive amount of users (more than 1k)
- Don’t have enough time to move things on your own
- Doing it for the very first time with no external help
If any of these things ring a bell, consider using a third-party application that would help you do all of the above.
Prepare Work to Do When Using Our Service
Now what we discussed above was assuming that you are doing the migration process on your own. If you don’t want to deal with all of the above and need a more streamlined process that you are willing to pay extra, this is the section for you.
This is the same process as above but here’s another thing. You don’t need to scroll through the unwanted things as you can unmark them later when doing the data mapping process. What’s data mapping? Well, our tool allows you to map records you’d like to move to specific fields. If you don’t want them to move, you don’t need to mark them. Pretty simple.
Ensure Tier Parity
This is very important because if you are moving things from a higher plan to a lower tier one (or vice versa), you will encounter a situation where you’ll have data you won’t where to store. If you are consciously downshifting then you might want to consider storing that data on a CSV file for later use using our service.
Configure the Plats
Similarly to the manual process, you will also need to configure your platforms before moving things. This includes settings, automations, notifications, reports, etc. You might also want to make sure these preparations take place to avoid any errors:
- Set up all custom fields in the needed projects.
- Create all Agent profiles and add them to the necessary Projects with a Service Desk Team role in your target account to ensure the right ticket assignment. Also, make sure their emails in the source and target systems are the exact match.
- Turn on the Public Signup feature to enable Customer profiles migration.
- Make sure you're migrating only to Classic Jira Service Desk projects (the peculiarities of migrating to Next-gen projects here).
Now that you've done all the necessary preparations for your import to Jira Service Desk, you can move on to the process itself. To move to Jira Service Desk with our service:
1. Register with our website, go to the Migration Wizard and start a new data migration.
2. Select your old platform and provide the necessary credentials to connect it with our tool.
3. Similarly, connect the Jira Service Desk as your target platform.
4. As soon as the bridge between the system is established, you can pick the objects for data migration and, also, change the mapping of the ticket fields (if needed).
5. Now, when everything is ready, start the free demo migration. This is the process of migrating a small bunch of your tickets to the new system to ensure everything goes smoothly.
6. If you're happy with the results, it's high time to start the full process.
After you finish moving your records to the new platform, don’t celebrate just yet. You are not officially in the launch phase yet. This is the last phase of Jira migration plan. And it has its own set of preparations and things to know and follow so let’s take a look at some of the most vital ones.
After you are ready with the migration, your number one priority would be to facilitate your workers to their respective spaces. Your team will be lost and will certainly have difficulties adapting to the new platform. The best course of action would be to form a small leadership team that you can personally teach. These people can then pass the knowledge they acquired to the rest of the department.
This is a period that you must follow with extreme attention as this is where all the “bad” things happen. New tools, new errors, new missed deadlines, you get the idea. We advise that you set up a monitoring team if your company has a lot of employees. This team will learn about the errors and report back to you so that you can solve them more effectively.
Congrats, you made it to the end and moved all your stuff. Time for a drink or two!
And there you go. That's all for Jira migration plan. The process of migration can be hard but totally worth it. While our plan isn’t perfect, it can be used as a blueprint that you can use to move things. Every company is unique and not all steps apply so be sure to make the proper adjustments. And if you need help doing so, just contact us and we’ll make sure everything will go as intended.
Move your data to Jira Service Desk
Set up a secure automated migration.