Hey everyone,
I’m trying to move about 1500 entries from our Bugzilla database to JIRA. We’ve just started using JIRA and I’m not sure how to handle the different levels in Bugzilla.
I want to keep all the Bugzilla stuff in one JIRA project. This way, it’s all together and doesn’t clutter the main JIRA project list with department-specific Bugzilla products.
I’m considering using custom fields in JIRA to mirror Bugzilla’s product and component hierarchy, and maybe even setting up a custom JIRA page to display the right components when a product is selected. I’m aware of JIRA’s customizability but need advice on the best approach.
So, my questions are:
- Is using custom fields the preferred method to represent Bugzilla products and components in JIRA? What potential drawbacks might there be?
- If yes, how can this be implemented, especially the dynamic form aspect?
- If not, what alternatives do you suggest?
Thanks for any help!
Having gone through a similar migration process, I can share some insights. Custom fields can work, but they have limitations. We found that using JIRA’s native project and component structure was more effective in the long run.
Instead of one big project, consider creating a ‘Bugzilla Migration’ project category in JIRA. Then, set up individual projects for each major Bugzilla product and use JIRA components to represent the respective Bugzilla components. This approach leverages JIRA’s built-in hierarchy and reporting capabilities.
For the migration itself, we used the JIRA CSV importer and wrote scripts to transform Bugzilla data into the JIRA CSV format, mapping fields appropriately. Although mapping Bugzilla’s workflow states to JIRA’s required creating custom workflows, the effort paid off by streamlining the transition. Remember, focus on preserving critical data and workflows, and be prepared for some manual cleanup after the migration.
yo, i’ve been thru this mess before. don’t bother with custom fields, they’re a pain. use JIRA’s built-in stuff instead. make a project for each bugzilla product and use components for the subparts. it’s way easier to manage longterm. for moving data, the CSV importer works pretty good. just script it to convert bugzilla info to JIRA format. good luck!
Based on my experience, I’d recommend against using custom fields to replicate Bugzilla’s structure in JIRA. While it might seem intuitive, it can lead to maintenance headaches down the line. Instead, consider leveraging JIRA’s native project and component structure.
Create a separate project for your Bugzilla migration, then use JIRA’s components to represent Bugzilla’s products and components. This approach aligns better with JIRA’s design and will make future management easier. For the migration process, JIRA’s CSV importer is quite robust. You can script the data extraction from Bugzilla and transformation into JIRA’s format.
Keep in mind that you might need to adjust some workflows and field mappings. It’s also worth considering which historical data is truly necessary to migrate. Sometimes, a clean slate with only recent or active issues can be beneficial for long-term JIRA health.