Exporting Cloud & Next Gen Projects = Governance Nigthmare

[Sebastian Kouba]

It seems to me that next gen projects are a perfect Pandora's Box that Atlassian opened without asking questions.

- Everybody can create next gen projects
- There seemingly is no way to disable this
- You can't export as soon as there is a next gen Project in the system

Well, I'm trying to create an export and I'm constantly chasing people down and failing at that.

If you are trying to make an export you end up chasing after people and the projects they create. Often these projects are just a test to see what happens when you do. I really wonder if anybody has thought about the impact of how next gen projects are handled at all.

A lot of governance goes out the window as soon as the next gen projects are unleashed. People can create all kinds of config items that may slow down the entire system as well as blocking export. If you have 2k users and half of them create a project just to see if they can create fields also, that is going to have an impact on the system, aside from the export issue.

How am I supposed to reign this in?

[Scott Theus · Accepted solution]

Hi @Sebastian Kouba,

I have some governance restrictions in my organization as well. There is a global permission for creating next-gen projects, you can remove the "Anyone" setting and add permissions for the groups you want to have access.  here is some info an Atlassian Team member sent me:

https://confluence.atlassian.com/adminjiracloud/managing-global-permissions-776636359.html

Hope this helps.

-Scott 

[Sebastian Kouba]

I did not see that permission earlier. Thanks for pointing this out!

That helps a lot. The way the next gen projects block server exports is still far from ideal.

[Steve A]

OK. Great.

[Nic Brough -Adaptavist-]

Could you explain 

"You can't export as soon as there is a next gen Project in the system"?

I ask because I've just taken an export of a Cloud system with Next-Gen projects and imported into a server.

[Sebastian Kouba]

You cannot back up for Server.

[Xavier Ferro]

Thanks @Sebastian Koubafor the feedback. We do understand that not being able to export to Server when there are next-gen projects is far from ideal. Few points about the reasoning behind that decision:

• There is no such a concept of next-gen projects in Jira Server. 
• In order to create such automated processes, we would need to expose all the internal schemes when migrating to Server so next-gen projects would look lie classic projects in Jira Server. That would mean to auto-generate few schemes and names that are far from ideal. Not only that, permissions would need to adjust to classic Jira.
• That would mean that users that created next-gen projects would have a completely different experience and could be very confused about the overall process itself.

In order to avoid all these problems, we are explicitly asking the user running the export (Admin) to take specific steps to manage all these edge cases. Therefore, next-gen projects can be removed or moved to classic projects which we thought would bring a more controlled environment for such process.

Still, please let us know any other ideas/concerns that you might have about next-gen. I hope the answer helps.

Best regards

[Sebastian Kouba]

I totally understand.

Maybe allowing the export but excluding the next gen Projects would be a more gentle solution rather than making me delete or migrate them? If you want to export a next gen project then yes, that's an issue but aside from that, why not just exclude them?

We have our issue under control but we had to disable next gen (which I think can be a good idea in terms of user friendliness but also lead to issues with governance of Statuses etc.)

[Marc Gebauer]

... or modify the import so it ignores the next-gen-projects in the export.

I'd like to migrate a JIRA-cloud-instance into our JIRA-server and there is one next-gen-project in it (and much more classic projects). I'd like to test the import on our test-environment but to be able to import the cloud-export I have to migrate the next-gen-project into a classic-project - which is "not easy" because the cloud-instance is in production-state at the moment and it would cause a lot of trouble...

[Artem Fomin]

Is there an easy way to identify the list of Next-Gen projects on the system?

[Xavier Ferro]

Hi @Artem Fomin,

yes you can. If you call

GET /rest/api/3/project

is going to return an array of Project objects which contain an attribute "style" with possible values (classic | next-gen)

You are looking for projects that are next-gen ones.

[Artem Fomin]

@Xavier Ferro - thank you for this suggestion. I was just given another option:

As for verifying which projects are Next-Gen projects, what can be done is access the backup manager page, located under Jira Settings > System > Backup manager. There, under Back up for server, you should see a list of all existing Next-Gen projects on your site.

[Mauricio GALVEZ]

@Xavier Ferro there is any information about the fact that Next-Gen will be available for JIRA Server on the future?

[jameer ahamad]

why can't we exclude next-gen projects from back up for server ?

[Damon Ramsey]

Yes I must say this is totally ridiculous. Stuck right now on my move to Jira Server because of this. 

[Ashley Watson]

We have situations where we need to migrate a Jira cloud project to another Jira cloud instance. The only way we can achieve this right now is to do a reverse migration which would have meant;

1. Take a cloud backup for server.

2. Import cloud backup onto server,

3. Use the migration assistant to go to another cloud instance.

Because some of our teams are making heavy use of the NextGen projects and the fact the migration assistant doesn't go cloud->cloud, We are now having to consider taking the following process - which just isn't viable at scale;

1. Take a cloud backup for c;loud.

2. Import cloud backup onto another temporary cloud instance,

3. Remove NextGen projects

4. Take as cloud backup for server

5. Import cloud backup onto server

6. Use the migration assistant to go to another cloud instance.

As you can imagine, this just is not viable.

As an IT services company, this use case is increasingly common as we have historically tenanted many customer projects on our main group cloud instance, only for many of the customers to start adopting Atlassian cloud at scale themselves. Out customers now want their data to be transferred out of our cloud instance to theirs, and we can not easily do this even taking into account convoluted approaches such as reverse migrations.

The other aspect is that the fact we can no longer make backups for server, means our DR strategy is compromised.

We are a large enterprise consumer of Atlassian products, and we would expect Atlassain to urgently address these deficiencies.

To put a figure on the value of our business our monthly cloud spend with Atlassian cloud products is currently more than US$10k per month and growing.

Please advise.

[Dima Lazarchuk]

Hey Ashley, try our service Help Desk Migration https://help-desk-migration.com

we can transfer your data from one Jira to another easily.