What should I check before migrating Jira Server to Jira Cloud?

[Alex Taylor]

I’m planning a migration from Jira Server to Jira Cloud and want to make sure I understand the main compatibility and migration issues beforehand. Are there any specific areas I should review, such as apps, custom workflows, permissions, automation, attachments, or user accounts? I’d also appreciate any recommendations for testing the migration before moving production data.

[Carlos Garcia Navarro]

Hi @Alex Taylor ,

Welcome to the Community! 

You can review each of those areas before migrating. Jira Cloud Migration Assistant (JCMA) moves most core Jira data, but it is not a byte-for-byte conversion of Jira Server.

Compatibility checklist

Area	What to review
Marketplace apps	Inventory every installed app, confirm that a Cloud version exists, compare feature parity and licensing, and check whether the vendor provides a JCMA migration path for app data. App custom fields, workflow functions, dashboard gadgets, or stored data may require vendor-specific migration steps or manual reconstruction. Use JCMA’s app assessment and contact critical app vendors early. App assessment guidance
Workflows	Test every status and transition, especially validators, conditions, triggers, scripted functions, and post-functions supplied by apps. Basic workflows and supported rules migrate, but workflow triggers, some properties, diagram positioning, and unsupported app functions may not. Notification schemes also have limitations: custom events and user-defined custom notifications do not migrate automatically.
Permissions and security	Permission schemes, project roles, and issue-security configuration generally migrate, but global permissions do not. Review group memberships, project access, browse permissions, issue-security levels, anonymous access, and administrator access. Resolve duplicate group names carefully because merging groups can unintentionally expand permissions.
Automation	Inventory project and global rules, rule actors, webhooks, email actions, app actions, and cross-project references. Migrated automation rules are disabled initially in Cloud. Actors, audit logs, performance data, and global settings are not migrated, while some triggers/actions are only partially supported or unsupported. Reconfigure credentials and enable rules only after testing. Automation migration details
Attachments	Attachments normally migrate with issues, but validate counts, file sizes, filenames, permissions, thumbnails, and a sample of older and larger files. Large attachment volumes can materially affect the migration window; JCMA supports migrating attachments in advance to reduce downtime.
Users and groups	Clean up invalid or duplicate email addresses, inactive accounts, obsolete groups, external directories, and licensing groups. Only users and groups from active directories migrate. Passwords, avatars, personal time zones, and some profile properties do not; without SSO, users may need to reset passwords. Deleted users associated with migrated projects are represented as former users. User migration behavior
Boards, filters, and dashboards	Check ownership and sharing permissions, filters referring to projects outside the migration scope, cross-project boards, subscriptions, and third-party gadgets. Some dashboards and gadgets require separate selection or recreation. Dashboard migration limitations
Custom fields and data	Identify app-provided field types, duplicated fields, unused configurations, contexts, screens, and very large option lists. Some unsupported app fields require recreating the field in Cloud and topping up data through CSV.
Integrations	Reconfigure API clients, application links, OAuth/API tokens, webhooks, mail handlers, issue collectors, scripts, CI/CD integrations, and hard-coded Server URLs. Webhooks, mail handlers, and some links are not migrated automatically.

Atlassian maintains a detailed JCMA migrated/not-migrated inventory, which should be checked against your exact JCMA version.

Recommended testing approach

1. Clean up first: archive or remove obsolete projects, users, groups, filters, workflows, custom fields, and apps.
2. Run JCMA assessment and pre-migration checks: resolve all errors and consciously accept or document every warning.
3. Use a separate Cloud trial or sandbox: configure the intended Cloud plan, apps, identity provider, SSO, and provisioning first.
4. Run a representative pilot: include complex workflows, app-heavy projects, Jira Software boards, Jira Service Management projects, large attachments, and cross-project dependencies.
5. Perform a production-scale rehearsal: use the same migration sequence and approximately the same data volume planned for cutover. Record duration, failures, manual remediation, and expected downtime.
6. Conduct role-based UAT: have administrators, project leads, developers, service agents, customers, and ordinary users perform real tasks—creating and transitioning issues, running automation, searching with JQL, viewing boards, handling requests, and downloading attachments.
7. Reconcile results: compare project and issue counts, attachment counts, users/groups, permissions, workflows, filters, boards, dashboards, automation, comments, worklogs, and app data.
8. Create a cutover runbook: include the change freeze, final backup, migration order, responsible owners, validation gates, communications, go/no-go criteria, and rollback decision point.

One important testing detail: JCMA generally adds data without overwriting existing Cloud data. Repeated tests can therefore create conflicts or duplicates unless the test site is reset or migrated projects are removed appropriately. Atlassian’s full recommended process is documented in Test your migration to Cloud.