Queue narration over flashbacks...
That was completed a month or two before we shifted focus to this effort, and was key in it becoming the Utopia we wanted. We chose it because it was the easier of the two operations to...
1. Get on the same version
2. Align apps and groups
3. Export/import spaces
We learned some valuable lessons about the two teams that managed the applications in real time. First, the other team had the advantage in infrastructure setup, but they gave the customers whatever they asked for, and their leadership suffered from "paralysis by analysis." My team, on the other hand, was a little more "high-speed, low-drag" when it came to planning, and made the customer fight for any changes, but we already had organized well-defined processes around the front end management.
Those learnings about how our teams best interacted and where strengths and weakness lay resulted in The Plan.
Because my instance was the "cleaner" of the two, and was already operating out of a standardized configuration to match the company's newly-designed process, and it housed both development and support projects (the other team used Version One for development teams and Jira for support...), it was decided that all projects would migrate to it. We chose to focus on Version One first because of several factors, but it was mostly the licensing renewal time, and the fact we could get all development projects in a centralized location for metrics/reporting.
The projects in Version One were already aligned to the same process our Jira had for development work (naming conventions, workflows, sprint schedules, etc ...). When the company was designing the new process, we insisted on it being that way, knowing the work would be centralized at some point. The only things we really had to focus on were custom fields that those projects used as they were focused on a different technical aspect of the business. Instead of our usual "prove to me why you need this" approach to customizations, we sat with the teams to understand what they were doing with this information in the end. Come to find out, some of it was just "the way" and had no use other than filling it out. GONE. On the other hand, some of the fields allowed the information to be dissected in a way our project teams weren't doing, and that provided great insight for not only management, but the teams themselves. MADE PART OF THE STANDARD.
Once that was completed, it was just a matter of actually cutting over the data. We decided that only open issues would be moved, and that a handful of licenses would be retained for one year for historical/audit purposes. After that time, we would take an export of the DB for any future needs. The actual migration of the data was easy once we got a process in place. First, we informed the teams of what was going to take place and when. Most were already familiar with Jira, so no training was needed. We already used Tasktop in our day-to-day work, and although not necessarily designed or intended for our purpose, we used it to one-way sync the needed issues into the target Jira. There were a few hiccups like assignees/reporters that were no longer with the company, so prior to initiating the sync we would have the teams review their open issues and change to active employees. But other than that, we were able to quickly migrate the ~100 projects into Jira and put that system behind us. Then we hit "The Reset."