Here at Alley, we’ve recently completed a six-month project to migrate from Redmine to JIRA for issue tracking and project management. Migrating hundreds of users, tens of thousands of issues, and hundreds of thousands of comments is a daunting task, but we managed it without disrupting our projects, clients, or day-to-day work.
We started using Redmine as our project management software in 2011, and it worked well for us for years after. We invested lots of time in customizations for Redmine such as configurable Kanban boards, an enhanced timesheet interface, and keyboard shortcuts. While the Redmine open-source project stayed current with Ruby on Rails, its underlying framework, it didn’t keep pace with major internet trends like the mobile web. As its user experience stagnated, our clients and team started to grumble about the usability of its most basic features, like time tracking and issue reporting.
The real turning point for us came when we fully embraced Agile as our project management methodology in the midst of a year-long agency-wide transformation of our company KPIs. Both of these initiatives demanded very specific features — moving to Agile meant that we needed tools to manage projects with Scrum, which we use for large-scale product development, and Kanban, which we use for ongoing maintenance. Our new financial controls demanded much more sophisticated time tracking and reporting features. And none of these initiatives would make any difference to our business if we couldn’t easily deploy our data to make decisions about project planning, team assignments, and hiring.
We looked hard at building further customizations to Redmine, but only a handful of our development team are familiar with Ruby on Rails, and we tend to focus our open-source contributions on the tools close to our core expertise — building large-scale digital publishing systems. Our CEO Austin built most of our custom Redmine plugins himself when Alley was a much smaller team, but he needed to focus on scaling our company. Still, we started creating an Elasticsearch interface to Redmine that would unlock the data we needed to make better decisions. When we scoped out the rest of the project, though, we realized that it would probably take us at least through 2017 to deliver these systems, and even then we’d very likely need to embark on a major project to revamp Redmine’s user experience.
We evaluated dozens of issue management systems and a handful of systems that provide both issue management and time tracking. It was a difficult decision for us to leave an open-source package for a paid alternative, but we concluded we had no other viable option when we found no other open-source system that offered SaaS hosting and the flexibility we needed. We then realized that most SaaS platforms that provide both issue management and time tracking don’t provide the best of either solution, so we narrowed our focus to the best standalone systems. We picked JIRA first, and it was an easy call to make. JIRA is a well-known standard in the industry, and we’d experienced it firsthand since many of our clients use it internally. Time tracking also turned out to be an easy call — Harvest offered a great user experience for our team, an excellent desktop application, and a decent integration with JIRA so we could add ticket information to time entries.
Moreover, Harvest offers Harvest Forecast, which allows us to plan our future project assignments week by week, so we can make better decisions about hiring and project planning. For years we had relied on a cumbersome, color-coded Google Sheet which grew larger and spawned more colors as our team grew and our business expanded. Replacing this document was a prime objective of the project we had originally contemplated to build atop Redmine. Thankfully, Forecast met almost every requirement of the system we had contemplated building ourselves, effectively replacing months of software development with a reasonably priced, fully hosted system.
When we had settled on JIRA and Harvest, we signed up for trial accounts of each and started planning the transition. We decided in mid-April of 2016 that we would complete our transition by July 1st. We would progressively move projects from Redmine to JIRA, but would continue tracking time in Redmine through June and then would switch over en masse on July 1st. We bill most of our clients on a monthly basis, and having two active time-tracking systems didn’t seem like a good option.
We considered hiring a JIRA consultant to help us configure JIRA and execute the migration, but we were worried that we’d add overhead to the process in conveying our needs. So ultimately, we handled the transition work ourselves while carrying on our normal responsibilities.
Here’s how we did it:
- Aided by Atlassian’s user guides and a number of helpful blog posts from other organizations, we handled all JIRA configurations ourselves. We created workflows and screens for Scrum and Kanban, along with a simple workflow that mirrored our pre-Agile process for projects that weren’t quite ready to transition.
- We created a permissions scheme that allows our team to see all our projects while restricting clients and other guest users to a specific set of projects.
- One thing we liked about Redmine was a plugin that allowed us to include a checklist on any ticket. JIRA handles this via sub-tasks, but there are several plugins available that are closer to what we had in Redmine. We evaluated these plugins but ultimately decided to just use sub-tasks.
- We built an integration for Alleybot, our Hubot Slack robot, to provide contextual information anytime someone uses a ticket number in a Slack chat.
- JIRA supports direct migration from Redmine using its API, so we were able to move tickets, users, attachments, and comments quickly and easily. We created a schedule that laid out when each client would be migrated to JIRA, and we ran most migrations over a one-week period in June.
- JIRA’s Redmine migration toolkit didn’t support Redmine’s checklist plugin, so we wrote a script which flattened all checklists into the body of the ticket. Our project management team reviewed these tickets and converted active checklists into sub-tasks.
- We created user accounts for our team and added each client and project to Harvest. Harvest and JIRA both support a short name for each project, like “AIW” for Alley Interactive Website. In JIRA, it’s known as a project key, and is the first part of any ticket number, for example, AIW-110. In Harvest it’s known as a project code. We ensured that these short names lined up, which turned out to be imperative for future integrations.
- We activated the Harvest plugin for JIRA to simplify tracking time to individual tickets. Most of our team members now use this feature every day.
- Once Harvest was configured, we activated Harvest Forecast, which automatically imports Harvest data. We loaded Forecast with ongoing project expectations and were able to immediately use it for project assignments.
We hit our July 1st deadline and were able to sunset Redmine, although it will stay online through the end of the year just in case we missed something. While we have more work still to come — for example, we’re currently integrating data from Harvest and JIRA in a dashboard that gives our leadership team and our clients a real-time snapshot of project performance but we are far ahead of the schedule we had set for ourselves on Redmine. In the course of just a few months, we saved ourselves hundreds of hours of work on Redmine, improved our team’s time-tracking accuracy simply by improving the UX of their timesheet, and implemented the business intelligence that we need to make better decisions about the future of our company.
Have questions about our transition? We’re happy to help! Drop us a line at email@example.com.