Jira Cloud Migration Checklist 2026: Everything You Need to Know

Why Migrate to Jira Cloud in 2026?

Atlassian ended support for Jira Server in February 2024. If you're still running Server, you're operating unsupported software with no security patches. Jira Data Center is still supported, but the cost and operational overhead of running your own infrastructure rarely makes sense for teams under 500 users.

Jira Cloud offers automatic upgrades, better mobile apps, native AI features (Atlassian Intelligence), and deeper integrations with modern DevOps toolchains. For most teams, the question is no longer *whether* to migrate — it's *how* to do it without losing data or disrupting delivery.

Phase 1: Pre-Migration Assessment (2–4 Weeks Before)

1. Audit Your Current Instance

Before touching anything, understand what you have:

• ▹Project count: How many projects, boards, and issue types?
• ▹User count: Total licensed users and any inactive accounts to clean up
• ▹Issue volume: Total issues across all projects (affects migration time)
• ▹Custom fields: List all custom fields and which projects use them
• ▹Workflows: Document every custom workflow and its transitions
• ▹Automation rules: Export all Jira Automation rules for review
• ▹Dashboards & filters: Identify shared vs. personal dashboards

2. App Compatibility Check

This is the most critical step. Every Marketplace app you use must have a Cloud version, or you need a plan to replace it.

Go to the Atlassian Cloud Migration Assistant and run an app assessment. Apps fall into three categories:

• ▹Cloud equivalent available: Migrate as normal
• ▹Partial feature parity: Review what's missing and decide if it's acceptable
• ▹No Cloud version: Find an alternative or build a workaround before migration

Common apps with Cloud gaps include time-tracking tools, advanced reporting apps, and heavily customised ScriptRunner scripts.

3. Data Clean-up

Don't migrate technical debt. Before you run the migration:

• ▹Archive projects that haven't been active in 12+ months
• ▹Delete or merge duplicate issue types
• ▹Remove unused custom fields (each one adds complexity)
• ▹Deactivate users who've left the organisation
• ▹Consolidate permission schemes where possible

Phase 2: Migration Planning (1–2 Weeks Before)

4. Choose Your Migration Method

Atlassian provides three migration paths:

Cloud Migration Assistant (CMA) — The recommended approach for most migrations. It's a free tool that handles project migration, user migration, and app migration in one place.

CSV Import — Only suitable for very small, simple instances. Not recommended for production migrations.

Manual re-creation — For very old Server instances where CMA struggles. Rarely needed.

5. Plan Your User Migration

Users must exist in your Atlassian Cloud organisation before the migration runs. Options:

• ▹Invite individually: Fine for small teams (under 20 users)
• ▹CSV bulk invite: Upload a CSV of email addresses
• ▹Identity provider sync (SSO/SCIM): Best for larger organisations — sync from Okta, Azure AD, or Google Workspace

Users who haven't accepted their invite before migration will have their issues assigned to a placeholder account. Always allow 48 hours for invite acceptance.

6. Set Up Your Cloud Site

Before migrating: create your Atlassian Cloud site at atlassian.net, configure your identity provider if using SSO, purchase the correct Cloud tier (Standard, Premium, or Enterprise), install Cloud versions of your Marketplace apps, and configure global permissions and user groups.

7. Define Your Cutover Window

Pick a low-activity period — weekends or end of sprint work well. Plan for:

• ▹Migration duration: Roughly 1 hour per 100,000 issues as a starting estimate
• ▹Validation time: 2–4 hours post-migration to verify data integrity
• ▹Rollback window: Keep your Server instance available for 72 hours post-cutover

Phase 3: Test Migrations (1 Week Before)

8. Run a Full Test Migration

Never go live without running at least one — ideally two or three — complete test migrations first. A test migration reveals app compatibility issues, shows you the actual migration duration, lets you validate data integrity, and identifies custom field mapping issues.

9. Validate Test Migration Results

After each test migration, check:

• ▹[ ] All projects migrated with correct issue counts
• ▹[ ] Custom fields appear on issues with correct values
• ▹[ ] Workflow statuses match the original
• ▹[ ] Attachments are present (spot-check 20–30 issues)
• ▹[ ] Issue links and subtasks are intact
• ▹[ ] Sprints and boards are configured correctly
• ▹[ ] Automation rules have been re-enabled and tested
• ▹[ ] Apps are functioning as expected

10. Update Your Documentation

Write a runbook for the live cutover. Include: exact steps in order, who is responsible for each step, how to verify each step succeeded, rollback procedure if something goes wrong, and the Slack/Teams channel for migration day communication.

Phase 4: Live Cutover

11. Communicate to Your Users

Send a communication at least 5 business days before cutover covering: the new Jira Cloud URL, date and time of the cutover, expected downtime window, what users need to do (accept invite, bookmark new URL), and who to contact with issues.

12. Execute the Cutover

On migration day:

1. T-1 hour: Send final reminder to all users
2. T-0: Put Jira Server in read-only mode (Maintenance mode)
3. T+0: Start the Cloud Migration Assistant
4. During migration: Monitor progress in CMA dashboard
5. T+migration: Run validation checklist
6. T+validation: Update DNS/SSO redirects to Cloud URL
7. T+15 min: Send go-live announcement to all users

13. Post-Migration Validation

Before calling it done:

• ▹[ ] Can users log in to the Cloud instance?
• ▹[ ] Are all projects visible to the right people?
• ▹[ ] Do automation rules fire correctly? (Test manually)
• ▹[ ] Do integrations work? (Slack, GitHub, Jenkins, etc.)
• ▹[ ] Are webhooks still sending to the correct endpoints?
• ▹[ ] Do Confluence pages that reference Jira issues still link correctly?

Phase 5: Post-Migration (First 2 Weeks)

14. Monitor and Support

The first two weeks are when issues surface. Set up a dedicated migration support Slack channel, daily check-ins for the first week, and a feedback form for users to report issues.

15. Decommission Server (After 30 Days)

Once you're confident the Cloud migration is stable: take a final backup of the Server instance, export all data to XML (Jira's built-in backup), shut down the Server instance, then cancel the Server license.

Common Jira Cloud Migration Mistakes to Avoid

Skipping the app audit: Discovering a critical app has no Cloud version on cutover day is a migration-stopper. Always audit apps first.

Not cleaning up before migrating: Migrating 5 years of junk slows down the migration and makes the Cloud instance harder to manage.

Migrating everyone at once without testing invites: Always run a pilot group through the invite process first.

Underestimating automation re-work: Jira Automation rules migrate, but some trigger types and conditions behave differently in Cloud. Budget time to test and fix them.

No rollback plan: Always keep your Server instance available for at least 72 hours after cutover.

Need Help with Your Jira Cloud Migration?

We've completed 50+ Jira Cloud migrations — from 10-user startups to 800-project enterprise instances. Every migration comes with a fixed scope, a dedicated engineer, and a zero-data-loss guarantee.

Get a free migration assessment →