An overhauled configuration experience that makes Jira faster and easier to set up

New boards that allow you to mix and match the best features of Scrum and Kanban

A new roadmap that improves your ability to plan long-term and share your plans with stakeholders (This would be a big win for us and is the primary reason we’re interested in moving to a next-gen project)

A more detailed list of features and difference with the current project types can be found here.

Unfortunately, this is not something that can just be enabled for existing projects, a new next-gen project must be created and then the classic project is migrated over to the next-gen project. While this can be somewhat painless (the process is detailed here), there are a few significant caveats to the migration process:

Epic links and issue links: Any issue links in your classic project will not exist in your next-gen project. The issues themselves will still exist, but the links between them won’t.

Subtasks: All subtasks will be lost in this migration process.

Custom fields: These must be recreated in your new next-gen project.

Story points estimation: This data will be lost, however you’ll be able to start using story points estimation by enabling the Estimation feature in your next-gen project.

The loss of Epic to Issue links and Story Points Estimations seems like a significant roadblock to us being able to perform this migration, as we have invested significantly in those features. However, I would love to hear if anyone has any ideas how we could work around this.

The next-gen project is looking pretty neat but I’m a little afraid that the trade-off for Roadmaps might be too much. Unless there is some way of automatically restoring linked issues and estimation points to the new project this might be a deal-breaker. I don’t think that migrating nearly six thousand tickets by hand is doable and I assume that simply letting them go is not acceptable. What we could do, though, is to keep the current project as a form of a time capsule and simply create a new, next-gen, project to be used from that point on.

I would say that the costs of migrating our project to the next-gen is too large because from what I understood after migrating we only get the roadmap feature - other features are available right now.

If we really want to move to the next-gen, I would agree with @ngraczewski that we should keep the current project as a time capsule and create a new next-gen project. After some time we could close it and use only the next-gen project.

I’d suggest that before we switch the OpenLMIS project over wholesale, we first switch a smaller project over and give it a try. Perhaps a service with a defined set of work and a dedicated team for a period of time? Reporting in 3.6 comes to mind given how clean the feature separation tends to be there.

One question I have that I didn’t see an answer to with a couple minutes of poking around is:

Does next-gen not have epics and issues inside them? Or is it just the migration doesn’t bring them over?

I thought I saw a reference on Atlassian’s site, though now I can’t find it, that the migration feature is still a work in progress. That suggests that perhaps we’ll see an answer to issue links and story point migration sometime in the future. No guarantees of course, though the answer to our trouble might simply be to just wait for other early adopters to iron the kinks out.