Here at Rigor, we have used Lighthouse to track development tickets ever since we were founded in 2010. In general, this platform has worked well for us, serving as a low-cost, lightweight issue tracker that integrates with Beanstalk, our Git hosting provider. As our team continues to grow, however, flexibility and transparency are paramount, and it has been a challenge making Lighthouse meet expanding requirements. As a result, we started exploring other issue tracking tools, and we ultimately decided to make the jump to JIRA. After a few weeks on the new platform, we wanted to share our motivations for switching, the pain points we encountered while migrating, and last but not least share some code to ease the migration for others.

Lighthouse is, in its own words, beautifully simple issue tracking. In the early days, this simplicity served us well, making it fast and easy to create, update, and close issues with little setup. As we added more projects and formalized more of our planning and estimation tasks, though, this simplicity became a constraint.

Lighthouse Limitations

The key limitations we ran into using Lighthouse were as follows:

  • Limited planning and estimation functionality
  • Developer-oriented interface with no dashboard
  • Oversimplified issue structure (no hierarchy)

First, sprint planning in Lighthouse is fairly limited. In our workflow, adding issues to a sprint meant creating a milestone with a date in the name and assigning issues to it. Although this approach did provide categorization for our tickets and narrow our focus, it lacked the estimation and reporting elements necessary to allow us to scope and track our sprints.

Second, sharing the status of issues with the sales and support teams is problematic in Lighthouse. We tried using project activity streams and setting up RSS feeds, but ultimately the Lighthouse format is not dashboard-friendly. An effective dashboard shouldn’t need an explanation.

Finally, Lighthouse does not allow issues to have sub-tasks. While this seemed trivial at first, we noticed a lot of noise in our development queue when we started enforcing story point estimates. We wanted to be able to create and estimate at the story-level, but track at a lower level of specificity where necessary. Unfortunately the lack of sub-tasks made this impossible.

Quick Tool Comparison

Once we decided to make a change, we started exploring tools that addressed our new needs without breaking the bank. A few of the more popular platforms came to mind immediately, including VersionOne, Pivotal Tracker, and JIRA. These all seemed like decent choices given their popularity in larger organizations. We also considered some lighter-weight options like Trello and Sprint.ly, but we feared that we might be sacrificing flexibility for simplicity again.

In the end, we landed on JIRA, as we preferred its simplified pricing (not per user and no project limitations) and liked its Agile plugin. This post isn’t really about which platform is best, so we’ll leave it at that.

Migration Process

Having selected JIRA as our new platform, we were excited to move everything over and get going. We quickly found Lighthouse’s export option and were overjoyed. The export should make importing into JIRA a breeze, right? Sadly, when we got the email from Lighthouse with the export download link, we discovered otherwise.

After unzipping the export of all of our Lighthouse issues, we realized that each issue lived in its own file. Making matters worse, each file was generically named ‘ticket’ and was nested inside its own issue-specific folder. We knew it was unlikely that the exported issues would be formatted for direct import into JIRA, but this was worse than we imagined. Instead of having to reformat a few columns in a CSV, we now had to combine all the files into a single file formatted for JIRA.

Lighthouse export file structure

 

Before writing scripts to rebuild the Lighthouse export, we had to choose between CSV and JSON formats for the final import file. The simplicity of CSV files is attractive, however JSON allows for more complex relationships, so we decided to use the JSON importer in JIRA over the CSV alternative.

JIRA import options

 

Armed with Ruby and a boatload of folders and files, we set out on our mission. The main challenges we ran into while writing the script included:

  • Creating JIRA comments and history from generic Lighthouse ticket ‘versions’
  • Saving commit history for issues
  • Including attached files in the import

The first challenge was just a matter of exploring the Lighthouse JSON format and parsing versions accordingly. To address the second issue, we decided to include commits as comments in JIRA. Although this doesn’t look as nice as the native Git integration in JIRA, it does the job of keeping a record of commits for a ticket.

As for the issue of attachments, we ended up using Amazon S3 to upload the local files and then referencing the S3 location in our JIRA import. Not only did this bypass the issue of having to upload directly to JIRA, but we figured it would be better to have these in a platform-agnostic location in case we ever change tools again.

Wrap Up

Ultimately, moving our issue tracking to JIRA gives us more project management features to better serve our growing team. Agile boards are great for our office dashboards, and the estimation and reporting tools help us better understand our velocity and plan future sprints.

Having lived through the pain of migrating all of our Lighthouse data, we wanted to save anyone else making this jump some trouble by sharing our code. This solution may be addressing a limited audience, but for anyone making this move, go check out our migration code on Github and put it to work for you!