We’re renaming ‘products’ to ‘apps’

Atlassian 'products’ are now ‘apps’. You may see both terms used across our documentation as we roll out this terminology change. Here’s why we’re making this change

How to migrate automation rules

When migrating to cloud using the Jira Cloud Migration Assistant, you can migrate your automation rules along with other project components. This page explains what automation rules you can migrate and how they work after migration.

Before you begin

  • Ensure the Automation for Jira plugin (version 7.2.6 or later) or Automation for Jira Lite plugin (version 7.3.3 or later) is enabled in your Data Center instance.

  • Review your automation rules, especially those with cross-project dependencies

  • Understand that some components may need reconfiguration after migration

  • The following features are not included in migration:

    • Automation audit logs

    • Performance insights

    • Global configuration settings

Understanding automation rules

Before migration, it's important to understand two types of automation rules:

  • Project rules: Specific to individual projects

  • Global rules: Apply across multiple projects

Migration options

When migrating automation rules, you have three options:

  • Migrates rules specific to your selected projects

  • Does not include global rules

  • Includes option to include or exclude disabled rules

Option 2: All automation rules

  • Migrates both project-specific and global rules

  • Only option that includes global automation rules

Option 3 : None

  • No automation rules will be migrated

 

Note: When re-migrating automation rules, your Data Center rules will always replace the existing Cloud rules. Any customizations or changes made to these rules in Cloud will be overwritten by your Data Center version.

Key migration behaviors

  • Rules referencing multiple projects will work partially until all referenced projects are migrated

  • Users and groups mentioned in rules are automatically included in migration

  • All migrated automation rules are disabled on the cloud by default post migration

Automation components supported in migration

When migrating automation rules, components have different levels of support in cloud. Here's what each status means:

  • Supported components: Migrate completely and work the same way in cloud

  • Partially supported components: Migrate but may have some limitations or behave differently in cloud

  • Unsupported components: Don't migrate and need to be recreated in cloud

Review your automation rules before migration to identify any using partially supported or unsupported components.

Fully supported components

These components migrate with complete functionality and work as expected in cloud:

Component type

Supported items

Triggers

  • Sprint Created

  • Sprint Started

  • Sprint Completed

  • Version Created

  • Version Released

  • Version Updated

  • Version Unreleased

  • Service Limit Breached

  • Work logged

  • SLA threshold breached

Actions

  • Assign Issue

  • Clone Issue

  • Create Issue

  • Create sub-tasks

  • Delete Comment

  • Edit Issue

  • Log Work

  • Manage Watchers

  • Create Variable

  • Delete Attachments

  • Log Action

  • Lookup Issues

Branches/Conditions

  • Advanced Compare Condition

  • Issue Attachments

  • JQL Condition

  • User Condition

  • If-else Block

  • Issue Fields Condition

Partially supported components

Partially supported components migrate to the cloud but might exhibit differences in functionality due to feature parity between Jira on-premise and cloud environments. This means that certain features or settings available on-premise may not exist or behave differently in the cloud, resulting in a slightly altered user experience.

It's important to verify each component post-migration to ensure it functions as expected. If you notice any discrepancies, you can manually adjust settings to align with your original setup.

What You Can Do:

  • Review and test: After migration, review all partially supported components and test their functionality in the cloud environment.

  • Manual adjustments: For any differences observed, manually reconfigure the components to match your needs.

Component

Partially supported components

Triggers

  • Issue Link Deleted

  • Issue Commented

  • Manual Trigger

  • Issue Updated

  • Issue Moved

  • Issue Created

  • Issue Assigned

  • Issue Deleted

  • Issue Linked

  • Scheduled

  • Multiple Issue Events

  • Issue Transitioned

  • Incoming Webhook

  • Field Value Changes

Actions

  • Set Entity Property

  • Delete Issue Links

  • Send Email

  • Link Issues

  • Transition Issue

  • Unrelease version

  • Release Version

  • Create Version

  • Comment On Issue

  • Delete Issue

  • Re-fetch Issue Data

  • Add Service Management Customer

  • Create Service Management request

Branches/Conditions

  • Branch Rule/Related Issue

  • Related Issue Condition

Unsupported components

These components won't migrate and need to be recreated in cloud if needed:

Component

Unsupported components

Triggers

  • Issue Archived

  • Issue Property Updated

  • Issue Restored

Actions

  • Archive Issue

  • Send Hipchat Message

  • Send Stride

  • Send Twilio notification

  • Publish Event

  • Send Microsoft Teams Message

  • Send Slack Message

  • Send Web Request

Branches/Conditions

--

More information and support

We have a number of channels available to help you with your migration.

Still need help?

The Atlassian Community is here for you.