Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Adding Multiple projects to scope of automation

arielei
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 21, 2025

Hello Community,

I face an issue where i'm migrating around 400 projects from DC to a Cloud that already have projects in it.

now, on the DC i had automations that were set Globally and if i will set it to that in cloud - it will catch also the existing project which i dont want.

is there a way to set only the projects that came from the migration?

 

Thanks

Ariel.

3 answers

2 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 22, 2025

Hi @arielei 

Short answer: In my opinion, unless there exists a very sophisticated, marketplace app which has up-to-the-minute handling for Cloud automation changes to do this, an export-edit-import approach may work, although every rule may need to be checked for safety. 

If your license level is high enough, perhaps ask the Atlassian Support team for suggestions.

 

Even for very simple rules, the projects-impacted information is stored all over the place, in the scope and individual components.  This may be observed looking at an exported JSON file for a rule.  I recall a "global" rule scope just keeps the highest level identifier, leaving off the added details for a specific project's identifier.

A couple of approaches to manage this might be:

  • Pre-work method
    • Investigate any tools which can update the rules in the DC site to change all the global scope references to a list of projects, or...
    • Try it manually:
      • Export all the current rules as JSON
      • Update one rule in Jira to change from "global" to "multiple-project", selecting all of the relevant projects
      • Re-export that rule, and identify the changes made for the scope references
      • Search-and-replace in the all-rules export to change them to multiple project
      • Re-import the rules (I do not have DC, so I do not know if you would need to remove the existing rules first, or it has the option to overwrite them during import.)
      • Migrate the projects
  • First migrate to a separate Cloud site, and investigate if there are tools to convert the scope, and then merge that separate Cloud site into your target one

 

Kind regards,
Bill

0 votes
Kinga_Getint
Atlassian Partner
October 22, 2025

Hey @arielei 

If, in your case, the option of using a third-party tool to handle the migration and post-migration configuration is acceptable, it might be worth giving the Getint Platform available on Atlassian Marketplace a try.

Getint can help you migrate only specific projects or configurations without impacting your existing Cloud setup.

For example:

  • You can connect your Data Center and Cloud instances, choose exactly which projects and fields to migrate.
  • Define separate integration scopes, so the automation or data sync runs only on migrated projects, not on the existing ones.
  • Once migration is complete, you can even keep a temporary sync between both environments to verify data or adjust automations safely before decommissioning DC.

So this approach lets you avoid touching global automation rules and gives you more control during and after migration. 

arielei
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 22, 2025

Thanks @Kinga_Getint , but this is irrelevant.

we have a plan to migrate using the JCMA tool. 

The problem is that i have a list of keys and i simply want to add them to the automation rule. 

Kinga_Getint
Atlassian Partner
October 22, 2025

Okay, thanks for clarification @arielei 

In that case, since you already have your migration planned with JCMA, the easiest way to handle this in automation would be to maybe filter by project keys directly?

For example by adding a condition like: Project key is in (PROJ1, PROJ2, PROJ3, ...)

That way, your global rule will only run for those migrated projects.

If you’re managing a long list (hundreds of keys), try to store them in a smart value (lookup table or JSON) so you don’t have to edit the rule every time, just update that reference when you add more migrated projects. And if later on you need to keep certain DC and Cloud projects in sync temporarily after. I think it should work fine.

0 votes
Gor Greyan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 21, 2025

Hi @arielei

I think one of the solutions could be using Project Categories.
Assign all migrated projects to a category→ “Migrated from DC”.
Use that in automation conditions.

arielei
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 22, 2025

Hello @Gor Greyan 

Thanks but thats not an option as it will brake other scripts that are using the category field.

 

any other solution?

Ariel.

Like Gor Greyan likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events