Advanced Microsoft Teams Connector for Jira - Migrating from Data Center to Cloud

This guide describes how to migrate the Advanced Microsoft Teams Connector for Jira from the Data Center version to the Cloud.

Before you start, review the feature differences between the Cloud and Data Center versions: Cloud vs Data Center comparison.

Prerequisites

• Jira Data Center instance with Advanced Microsoft Teams Connector for Jira (Data Center) installed, on version 20.1.12/30.0.6 or later (earlier versions don't support automatic migration - update the app first if you're behind).

• Jira Cloud instance with Advanced Microsoft Teams Connector for Jira (Cloud) installed. No further setup on the Cloud side is needed before migrating - no one needs to sign in first.

• Required user permissions:

  • Jira Data Center

    • Jira global administrator, to review the Cloud Migration tab, run pre-migration checks and export a reference copy of the configuration

    • Jira system administrator to install or update the Marketplace app

    • Space admin permissions if you have space-level configurations

  • Jira Cloud

    • Jira site administrator (or organisation admin) to install the Marketplace app and reconnect the Microsoft Teams bot after migration

    • A Microsoft 365 Global Administrator or Teams Administrator, if you plan to switch which instance Teams actions use (see below) - a Jira admin can view this setting but not change it

    • Space admin permissions if you have space-level configurations

Migration steps

Step 1. Migrate Jira data from Data Center to Cloud

To start this journey, it's recommended to use Cloud migration methods for Jira to ensure a successful migration.

If you use the Atlassian Migration Assistant, on Jira Data Center go to Jira administration → System → Migrate to Cloud and run the Jira Cloud Migration Assistant for your projects, work items, users and attachments. This same migration plan is where you'll also migrate the Microsoft Teams Connector app, in the steps below.

Already migrated your Jira data and don't want to run the Migration Assistant again just for this app? Skip ahead to Alternative: manual migration.

Step 2. Include the connector in your migration plan

Make sure Advanced Microsoft Teams Connector for Jira (Cloud) is installed on your Cloud site, then select it in your JCMA migration plan's list of apps to migrate.

Step 3. Review before you migrate

On Jira Data Center, go to Microsoft Teams administration > Cloud Migration and click Export as JSON to download the exact configuration JCMA will transfer. Review it for warnings, then run JCMA's pre-migration checks for this app:

Step 4. Run the migration

Start the migration plan. JCMA transfers the following automatically, with no manual recreation needed:

• Notification rules (global and project level)

• Notification rules (personal level)

• Global settings

• Managed URLs (called "Workflow URL Management" on Data Center)

What to expect when you review the results

A few differences between DC and Cloud show up automatically during migration - these are expected, not errors:

• A rule scoped to multiple projects becomes several rules. Cloud notification rules only support a single project each, so a Data Center rule covering more than one project is split into one Cloud rule per project during migration.

• Issue lifecycle events map onto work item transitions. Data Center's "issue opened / resolved / closed" events don't exist on Cloud, which only has transitions. Migration maps them onto the equivalent transition rather than dropping them - e.g. "issue resolved" and "issue closed" both become a transition-based rule.

• Notifications may arrive with a short delay you didn't see on DC. Cloud batches notifications into a roughly one-minute window by default; Data Center sends immediately. This can be confusing the first time if you're not expecting it.

You can see exactly what happened to each rule - including any split or remapped above - by opening Jira admin settings > Microsoft Teams > Data Center Migration > Imports in the Cloud app and selecting the import.

Step 5. Validate and cut over notifications

1. Trigger a matching Jira event for each new notification rule (create/update/comment/transition) and confirm the message lands in the expected Teams channel with the right content.

2. If possible, run DC and Cloud in parallel for a brief period to compare volume and content. Notifications are sent from every connected instance until you disable or remove the rules on the side you no longer need.

3. Once Cloud is verified, disable or delete the notifications on Data Center to avoid duplicate notifications, and uninstall the DC version when the instance is decommissioned.

This only covers notifications. Interactive Teams actions (search, tabs, bot commands) are controlled separately - see the next section.

Alternative: manual migration

If you've already migrated your Jira projects and data separately - for example, before this app supported the Cloud Migration Assistant, or you simply don't want to re-run a full JCMA plan - you can migrate this app's configuration on its own, without JCMA.

1. On Jira Data Center, go to Microsoft Teams administration > Cloud Migration and click Export as JSON. Save the file.

2. On Jira Cloud, go to Jira admin settings > Microsoft Teams > Data Center Migration > Imports and click Import from file. Select the file you exported.

3. Review the preview of what will be migrated, then start the import. Progress updates in real time.

4. When it finishes, you'll see a summary of items saved, disabled and skipped. Select the import to see the same per-rule detail (splits, remapped events, disabled rules and why) as the Cloud Migration Assistant path.

Manual imports and Cloud Migration Assistant imports both appear in the same Imports history, reviewed the same way - the end result is identical either way. Everything in What to expect when you review the results and Troubleshooting applies here too.

Which Jira instance Teams actions use

Most customers have both Data Center and Cloud connected to the same Microsoft Teams tenant for a while during migration. Here's what to expect during that period, and how to complete the cutover when you're ready.

Notifications vs. interactive actions

These are controlled separately, and it's worth keeping them distinct:

• Notifications are sent from every connected instance, for as long as rules exist on each - this is the notification cutover covered in Step 5 above.

• Interactive actions from Teams - creating issues, commenting, searching, running bot commands - can only go to one instance at a time: whichever one is set as active.

Completing a migration never switches this automatically

Finishing a migration - by either path above - does not change which instance is active. This is deliberate: migrations take time, and customers often want to test Cloud before cutting over, without disrupting anyone still using DC interactively.

Switching the active instance

Go to Jira admin settings > Microsoft Teams > Data Center Migration > Settings. You'll see every Jira instance connected to your Microsoft Teams tenant, with the currently active one marked. Select a different instance and confirm to make it active - this takes a short while to apply.

Switching is fully reversible - you can switch back to DC at any time the same way, and Teams actions will route there again.

Bot user mappings

Bot user mappings (which Jira account a Teams user is linked to) are not migrated as data. Instead:

• The first time an admin opens the Cloud app, signs in and gives consent, the app automatically tries to match existing Teams users to their Jira Cloud accounts.

• Anyone it can't match needs to type connect in their personal chat with the bot, or be handled from the User Configuration page.

• A Teams user can hold a separate mapping for each connected instance at once - one for DC, one for Cloud - rather than a single mapping that has to be replaced.

• The disconnect command now clears all of a user's mappings at once, not just the one for a single instance.

What users see if they're still mapped to the old instance

If a user is mapped to DC but Cloud is now the active instance, the next time they try an action from Teams they see a banner explaining this, and also get a message in their personal chat.

Acting on an old notification card

A notification card sent before the switch still came from whichever instance was active at the time. If a user tries to act on one of these older cards after the switch, they see this banner, quoted verbatim from the product:

The banner names the specific issue key the action will apply to, and the user also gets a personal chat message. The action itself is correctly applied to the new active instance, not the one the card was originally sent from - nothing is lost or silently dropped.

Post-migration checklist

• Reconnect the Microsoft Teams bot in the Cloud app.

• Check whether any users weren't automatically matched (see Bot user mappings above) and need to run connect themselves.

• Search the Cloud app for any rules that migrated disabled - this happens when a rule's saved filter no longer existed on Data Center. Re-enable them with a new filter or JQL.

• Heads-up for alert-type rules (SLA threshold alerts, "issues not transitioned" alerts): their "already alerted" history doesn't carry over, so they may treat every currently-matching issue as new and fire once for all of them on first run. Worth warning your team before it happens.

• Recreate Reports, Alerts, Admin Events and Custom Event Types in Cloud if you use them - these aren't migrated (see Step 4).

• Decide when to switch the active instance so Teams actions move to Cloud (see above) - there's no rush, and it's reversible.

Troubleshooting

Your Step 3 export includes a full list of migration warnings - use it to explain why a specific rule came over differently than expected:

If a specific rule "migrated but looks wrong," check whether it used a saved JQL filter rather than typed JQL. Filter IDs aren't preserved across the migration, so Cloud first tries to map the filter itself; if that fails, it falls back to the filter's raw JQL text carried over at export time.

A few things are permanently excluded by design and don't need fixing: the rule-tags index (rebuilds itself automatically), the in-memory message audit trail (was never persisted on Data Center), and - as noted above - alert "already sent" tracking history.

Contact us

If you have any questions or need help with migration, please contact our Support Team. Our dedicated team will answer all your questions and expertly guide you through the entire migration process.

Updated: October, 2026