Software migrations worksheet (Azure DevOps — Jira, ServiceNow-Jira, and more)
How long it takes to execute successful (f.e. Azure DevOps — Jira migration, ServiceNow-Jira migration)?
In short, we say 3 months.
Why? First, you need to think it through.
1. Discuss the scope with all stakeholders. What exactly do we need to migrate?
2. Preparing the tools — Azure DevOps, Jira, ServiceNow, Monday.com, Asana, Zendesk — those are all totally different platforms. Sure, they are all “Collaboration Software Tools”, but the logic how they work, the workflows, the setup, and the features vary. Some have all the fields you need ready out-of-the-box, in some you need to create them. Some fields can’t be migrated as is. You learn most of this, when preparing the tools for migration.
3. Test out the tool for migration in dev instances
4. Execute the migration
5. Transition period — the data might be now successfully migrated. But, are your people ready for it? What about those, who were on holidays, or maternity leave? To make them more comfortable, we suggest offering transition period (f.e. 2 weeks — 1 month), when both tools are working in sync. This way the people can still do they job in the new, and in the old tool, while learning.
What projects do you want to migrate?
Most tools for migrating software tools like Jira, ServiceNow, Zendesk, Azure DevOps are project based. So to migrate the tools, you actually need to migrate projects, types, and fields.
The first step in our worksheet is to decide, which projects you need to migrate.
What types within projects are needed (Bugs, Tasks, Incidents, etc.)?
When you know what projects you are migrating, now decide what types within projects you need to be migrated. Decide what to do with those, that are different- f.e. in ServiceNow we have “Incidents”, “Work Items” in Azure DevOps, and “Issues” in Jira. You may want to create the fields, with corresponding names (to map “Risk” in ADO, to “Risk” in Jira).
Is there any hierarchy? Do you have subtasks?
Do the mapping in our worksheet.
Field mapping
When types are mapped, decide what fields to you want to migrate. Title? Description? Assignees? Labels/Tags? Attachments, and comments? Are there any custom fields? What types are they (text/radio/checkbox)? Do you have all the fields created in both tools? Are they required? Are they on the creation screen?
Migrating only the issues with labels with custom JQL
To keep you new tool as clean as possible, you may want to migrate just the most crucial taks/issues/incidents. Add them specific label, f.e. “Jira-Migration”.
Timeframe
When all is set, decide how old issues do you need to move to a new tool. All the ones from 2021? And 2020? Just one month of 2019?
Testing
When the migration was executed, go to the reporting to see if everything was successful. It’s easy to forget some things — f.e. subtasks may not be migrated, if the parent wasn’t. It is not possible to create an issue, when some field is required, but there was no data to migrate, and so on. The tool will tell you everything, that happened to help you react.
Consulting
In some cases, you may want to get someone to do it all for you. If that’s your case, reach me out at jacek@getint.io, I’d be happy to help.
