🚧 Maintenance
Starting today, Zenhub will begin migrating all cloud customers to our new sub-issue based Epics & Projects. If you're new to sub-issues please check out our other changelog post which describes our vision in more detail.
With this migration, you'll gain more granular work hierarchy, improved organization, and clearer alignment between your daily tasks and strategic goals—all while preserving the developer-friendly workflow your team values.
The key benefits include:
- Additional levels of hierarchy to break down work more precisely
- Automatic enforcement of consistent work structures across teams
- Better visibility into how individual tasks connect to larger objectives
- Improved Timeline view replacing the old Roadmap for better project tracking
- Enhanced scalability as your organization grows
- Better GitHub integration (projects and epics converted to GitHub-based issues where possible)
In this post we wanted to communicate what you should expect as part of this transition which will occur over the next few weeks. Once complete, your Projects and Epics will be converted to Sub-issue based replacements, the updated Timeline view will replace the Roadmap, and you’ll enjoy additional levels of hierarchy to break your work down more granularly.
For all customers
- All your existing roadmaps will automatically migrate to the new "Timeline" page. The Roadmap page will disappear from the main menu.
- The "Epics" filter will disappear from the Work Tracker filter toolbar. To filter your board issues by a specific epic, you can use the new "Filter by" option in the "Goals & Planning" panel
- Projects will be converted to either:
- GitHub issues with the "Project" issue type, or
- Zenhub issues with the "Project" issue type
- The “Epic” option will disappear from the “Create” menu. To create an epic select create a
”GitHub Issue” or a “Zenhub Issue” and choose “Epic” as the issue type
- The “Epics” metadata will disappear from the issue page (for both GitHub and Zenhub issues). This information has moved to the “Parent” metadata field instead.
For customers using Zenhub-based Epics
- You will see your Epics in the "Goals & Planning" panel in the "Work Tracker" or in the "Timeline" page. The Epics page will disappear from the main menu.
- Epics will be converted to either:
- GitHub issues with the "Epic" issue type, or
- Zenhub issues with the "Epic" issue type
For customers using GitHub-powered Epics
If you are leveraging GitHub-powered Epics in Zenhub (aka. legacy epics), you should expect the following changes to your Zenhub data in the coming days:
- Epics will be tagged with the "Epic" issue type in both Zenhub & GitHub
- Epics will no longer show up on the Board by default -- they will appear in the new "Goals & Planning" panel
- If you would like to view these on the Board still, you can do this by enabling the "Epic" filter in the "Issue Types" dropdown, or updating the setting for Epics in your Issue Levels.
Known Limitations
- We have temporarily disabled the "Epic" filter and grouping options in the Velocity Report as it doesn't support the new sub-issues data structures. We plan to bring this back soon and make it even more robust (supporting different issue types other than just epics)
FAQ
How do I know if I’m using “Zenhub-based Epics” or “GitHub-powered Epics”?
If you see an “Epics” page in the main menu of Zenhub — you are using “Zenhub-based Epics”, otherwise you’re using “GitHub-powered Epics”.
How will Zenhub decide whether my Projects & Epics will become GitHub issues or Zenhub issues?
Our goal is to prioritize creating GitHub-based issues as much as possible, however, in situations where it may not be possible (ie. because Zenhub doesn't have the necessary permissions, we cannot reliably determine which repository the issue should be created in, GitHub fails to process the request, etc…) we will fall back to creating Zenhub issues.
How will Zenhub decide which GitHub repository to migrate my issues to?
We will do our best to determine this based on the configuration of your workspace and the repository of the parent issue. It’s possible we may not get this just right in 100% of the cases. If you are seeing incorrect placement feel free to reach out to us at support@zenhub.com with the details and we will correct the mistake.
If my issue is assigned to multiple Epics what will happen to it post migration?
An issue that belongs to multiple Epics will be migrated as a sub-issue only to the first Epic that contains it. In other Epics it will reference that issue as a blocking dependency.
After the migration some of my issues got duplicated with 1, 2, 3, etc… appended to the end. Why did this happen?
GitHub has a limitation of 100 maximum sub-issues. For the rare cases where your Zenhub Epics had more than 100 child issues, we created additional issue buckets to place the issues into. We recognize this is not ideal and apologize for the extra noise this creates.
After the migration some of my epics got closed. Why did this happen?
As part of this migration, we automatically closed any epics which were open but had no open children. Based on customer feedback, in 99% of cases those epics were open because a user forgot to close them. We recognize that this may not always be the right action to take. If you find that some of your epics were inadvertently closed due to this decision, please contact us at support@zenhub.com.
I received a bunch of email notifications in GitHub about new issues being created. Why did this happen?
As part of this migration, Zenhub Epics & Projects were converted into GitHub issues. We tried to respect the same issue metadata, content, and authors on those issues. Because new issues ended up being created in your GitHub repositories, if you were subscribed to email notifications in those repositories you will have been notified. We apologize for the extra noise this creates. This is a one-time migration and not something that will happen again. We hope the extra messaging we placed at the top of each migrated issues will help you clearly identify which notifications were related to the migration and which are regular GitHub notifications.