In our discovery and the surrounding discussion, the most promising replacement for JIRA was Huly, so I’ve been looking into what that migration would look like and I will share my thoughts here so that everyone can provide feedback and discovery potential pitfalls in my approach.
Huly is structured differently than Jira, so we should re-evaluate how we structure our data:
- First of all, Huly supports workspaces, which is a container above issues, so rather than having a different project for Serenity, Bebop, Falcon etc, we can give each team its own workspace.
- Now instead of having epics for each project we have, we can use projects. We regularly have tickets going off in thousands and Bebop is close to 10000. Just looking at an issue like BB-1234 or BB-3456 doesn’t tell me what it’s about, what project it’s related to etc. Instead, if we use a different key for each project we will be able to immediately get a lot more info.
- Huly doesn’t have accounts. We can investigate adding them, use custom fields or we can use labels, milestones or projects to determine account. For Clients, Huly has company records as part of it CRMish features.
- For reviewers, we can add a custom field, either two for Reviewer 1 and 2 or, we can create a Reviewer field that is an array of users that can support 2 or even more reviewers.
- Point scores can be added as a custom field.
- Instead of watchers you can use Collaborators in Huly, though this is a manual process.
- Huly has no sprints yet, so we need to work with upstream on that before a proper migration.
I see this migration working in the following potentially overlapping stages:
- Initial Discovery: The current stage
- Exploration: Set up staging instances, and perform initial test migrations
- Development: Upstream features we definitely need before a migration
- Huly Phase-in: All new projects created in Huly. At this stage we use both but all new projects “epics” etc are on Huly.
- Jira Phase out: All new tickets and activity on Huly, Jira only contains old data.
- Final Migration: All remaining old data will be moved over to an archived workspace retaining the old ticket ids if possible.
Given the above here is my rough estimation:
-
Discovery on Huly hosting 20h
- Huly has kubernetes config for self-hosting; however, it uses MongoDB. Huly supports other databases like PostgreSQL and CockroachDB, however the self-hosting config only supports Mongo, we’ll need to adapt it.
- Make a test deployment of Huly.
- Create tasks to make adjustments to Huly self-hosting for our needs.
-
Upstream changes to Huly self-hosting to adapt for our needs TBD
-
Discovery: Support for Sprints in Huly 40h
This is the biggest missing piece and in my conversation with them, I learned that they are working on a process management module that should support our needs. However, we should probably see if we can support them in prioritising this. They are also working on import/export, which again should be prioritised.
-
Create a stage deployment of Huly with a limited set of users 10h
This is a simple deployment after everything is already working.
-
Discovery: Export Data from JIRA 20h
- There are docs for exporting from JIRA Cloud, they might work with our instance as well.
- If the above docs work, we can simply take a dump of the data and start working on scripts.
-
Discovery: Import Data to Huly 20h
Huly supports importing from a “Uniform Format”, we can investigate creating scripts to convert from JIRA’s export format to Huly’s import format.
-
Create migration scripts 50h
- While a proper estimate will come with the above discovery, the above is a rough estimate that includes a test migration of limited data from JIRA → Export File → conversion script → Huly
- Huly doesn’t seem to have a traditional API. Instead it has a websocket-based API where all actions, events etc happen over a websocket.
-
Create user accounts, workspaces etc. 40h
- This will involve creating accounts for all users, and workspaces for each team.
- It will also involve creating Companies accounts etc.
-
Migrate active data 40h
This will involve migrating all data for active epics and tickets.
-
Migrate inactive data in archived workspace 40h
I’d appreciate if everyone could go through this when they find time and give feedback.