Risks/Recommendations with phased transition to Jira Service Desk

[Shannon]

We have a ticketing system used by many sub-departments of IT to manage their request queues (Service Desk, Cabling, Applications, etc). We would like to transition everyone to Jira Service Desk, but we would like to transition in phases; i.e. prove success with the Service Desk then roll in the other teams one at a time. 

In order to take this approach, we will need to operate both Jira Service Desk and our legacy ticketing system in parallel for approximately 8 months. 

I'm hoping we aren't the only ones to have travelled this path of parallel ticketing systems through a phased roll out. How should we handle the obvious concerns of not wanting our customer base to have two portals for any length of time, and not wanting our teams to have to manually create & maintain duplicate tickets? Are there any other issues with this approach that we should prepare for?

[Jack Brickey]

My recommendation is to choose a team that can cleanly move over and exist in a single solution (JSD) w/o working about the other tool. Once you are comfortable with the JSD then you simply set up the necessary projects and import the issues from the other departments/teams.

[Sofie-Anh Duranceau]

We did a similar phased approached moving to JSD. It went really smoothly. We did not need such a long period to transition though. This is up to you, but yes you will have to maintain 2 systems if you intend to phase it. Our key decision point was whether we would migrate historical data/tickets, but also open tickets on hold or pending resolution. 

In the end we decided to not migrate historical data and we do not regret it today. We kept record of the old system if we need to search through old cases. We also kept the old system open only for open tickets until completion to avoid having to duplicate. 

JSD is really easy to transition too, particularly if you are a Jira Software shop.