Splitting a JSM project into smaller projects/portals

[Chris Tolley]

Hi community,

We have just decided that our one large JSM project/portal (company-managed) would be better suited to three new, smaller team-managed projects.

While brainstorming this move, we've realised that all our request types, forms, automation rules, customers will need copying into the new projects.

The long way to do this will be to create a new project, then simply recreate all the configuration mentioned above. For forms, this is quite nice and easy and we can copy paste a full form into a newly created form, which is nice. For the other config items, not so nice.

So before we start on this, is there a "nice" way to tackle this? My first thought was that duplicating the initial project and then deleting any unwanted config items from each new project would be faster than recreating from scratch. Is something like this possible, perhaps with project export/import tools?

Let me know if anyone has ideas! Much appreciated. Chris.

[Nikola Perisic]

Hello @Chris Tolley 

Interesting thought indeed. However, when creating a team-managed JSM project, there is no option like you have in Jira to share settings within a project, which would save a lot of time.

Another thing that would be good is to have an export to CSV in JSM, so you could do an import from the CSV and save a lot of the time - however this would go for the issues not all of the other configurations like request types, workflows and automations.

And of course the cloud to cloud migration wouldn't work, because it migrates from one site to another.

So yes, everything would needed to be done from scratch.

[Chris Tolley]

That is unfortunate... Yes I was wondering if there is some magic possible with the migration tools, but I haven't seen anything that would help us either. Thanks for the response.

[Rebekka Heilmann _viadee_]

Hi @Chris Tolley 

what are the reasons for the split, if essentialy everthing is shared?

I would strongly advice against team-managed projects in this case, unless you want different configurations in the near future. With Company-Managed projects you can at least share Workflows, Issue Types and such without configuring it 3 times.

[Chris Tolley]

Hey @Rebekka Heilmann _viadee_  thanks for the response.

We're a small team of three Jira admins that manage the current shared portal. We are finding that teams (their agents) using the shared portal to manage their requests are wanting to do more and more with it, specifically automations, and our small team cannot keep up with the demand. As Jira admins, they need to wait for us for any workflow, custom field changes that are needed for their new automations.

When I say duplicating the original project, I mean eventually we would not have duplicated requests, I just thought that duplicating the project would be a quick way to recreate all the request types, if that makes sense?