If you’re running Jira Data Center and wondering what the move to Cloud actually involves, you’re not alone. Jira Cloud migration is one of the most-searched topics in the Atlassian community right now, and for good reason. With Atlassian setting a firm end-of-life date of March 28, 2029 for Data Center products, the question for most teams is no longer whether to migrate, but how to do it well.
The problem is that migration generates a lot of questions, from technical ones like “what data actually moves?” to practical ones like “how long will this take?” and “will we lose anything?” This Jira migration FAQ answers the 10 most common questions we hear from admins and IT teams, with clear, practical answers grounded in official Atlassian guidance.
Q1. Why should we migrate from Jira Data Center to Cloud at all?
The short answer: because staying on Data Center is no longer a long-term option.
In September 2025, Atlassian formally announced end-of-life for its Data Center products. The key milestone dates are:
- March 30, 2026 – New customers can no longer purchase Data Center subscriptions
- March 30, 2028 – Last date for existing customers to purchase, renew, or expand licenses
- March 28, 2029 – Full end of life. All Data Center subscriptions and associated Marketplace apps expire and become read-only
Beyond the deadline, there’s a compelling case for Cloud on its own merits: no infrastructure to manage, automatic updates, continuous feature releases, built-in scalability, and access to Atlassian’s AI capabilities (Atlassian Intelligence, Rovo) that are Cloud-exclusive.
Q2. What is the Jira Cloud Migration Assistant and how does it work?
The Jira Cloud Migration Assistant (JCMA) is Atlassian’s free, purpose-built tool for moving data from Jira Server or Data Center to Jira Cloud. It’s the recommended migration method for most organizations, and it’s available as a Marketplace app that can be installed directly on your Data Center instance without downtime or restarts.
Here’s what JCMA does:
- Assesses your instance – size, user validity, app compatibility, and migration readiness
- Prepares your data – identifies invalid user emails, untrusted domains, and configuration issues before migration starts
- Migrates your data – projects, users, groups, custom fields, workflows, attachments, and supported app data
- Tracks entities across migrations – so if you run a second migration later, JCMA knows what’s already been moved and avoids duplicates
JCMA supports both phased migrations (project by project) and full instance migrations. It runs pre-migration checks before execution and provides detailed logs so you can monitor progress and catch issues early.
👉 Full documentation: Atlassian JCMA Support Docs
Q3. What data gets migrated, and what doesn’t?
JCMA migrates a broad range of core Jira data, including:
- Projects, issues, subtasks, and issue history
- Users and groups
- Custom fields, workflows, issue types, statuses, and priorities
- Attachments and comments
- Boards, dashboards, filters, and saved searches
- Automation rules
- Supported Marketplace app data (where the app vendor supports JCMA)
What requires extra attention or may not migrate automatically:
- Marketplace apps – each app must be assessed individually; not all apps have Cloud equivalents or JCMA support
- Custom scripts and plugins – Data Center-specific customizations may need to be rebuilt in Cloud
- External integrations – integrations with third-party tools will need to be reconfigured post-migration
- Very large attachments – there are size and storage considerations on the Cloud side
A clean, well-audited instance migrates more reliably than a cluttered one. Review what gets migrated with JCMA for the full breakdown.
Q4. How long does Jira Data Center migration take?
There’s no single answer, migration duration depends heavily on the size and complexity of your instance. That said, here are general benchmarks:
- Small instances (a few projects, under 500 users): a few hours to half a day
- Medium instances (10-50 projects, 500-5,000 users): several hours to a full day
- Large or complex instances (50+ projects, thousands of users, large attachments): multiple days, often done in phases
The migration itself can be run while your Data Center instance stays live, JCMA is designed to minimize downtime. A final cutover window is needed at the end, but pre-migration of users, groups, and attachments can happen in advance, significantly reducing that window. For organizations migrating more than 1,000 seats, Atlassian’s FastShift program (part of the Atlassian Ascend initiative) offers dedicated support.
Q5. Will we experience downtime during migration?
This is one of the most common concerns, and the answer depends on how you plan the migration.
JCMA is specifically designed to minimize downtime. You can pre-migrate users, groups, and attachments in advance, so the final cutover window only needs to cover project data. The Data Center instance remains fully operational during most of the migration process.
⚠️ Important: Installing JCMA itself requires no downtime and no Jira restart. If the installation fails for any reason, it won’t affect your running instance.
Q6. Can Marketplace apps be migrated to Cloud?
Yes, many can, but not all. App migration during Jira Cloud migration is one of the areas that requires the most upfront planning.
JCMA includes an app assessment feature that scans all your installed Data Center apps and evaluates their Cloud readiness. For each app, you can mark it as:
- “Needed in cloud” – JCMA will attempt to migrate the app and its data
- “Not needed in cloud” – the app will be excluded from migration
Apps that support JCMA can have their data migrated automatically alongside Jira data. However, the Cloud version of the app must be installed on your Cloud instance before migration begins, otherwise app data migration will not proceed. For apps without Cloud equivalents, you’ll need to find alternatives or plan for manual data export.
👉 Check Atlassian’s app migration guidance for details on the assessment process.
Q7. What happens to users and permissions during migration?
User migration is one of the most technically nuanced parts of Jira Data Center migration, and one of the most common sources of post-migration issues. The core difference: Data Center uses username-based authentication, while Jira Cloud uses Atlassian Account IDs linked to email addresses.
JCMA’s Prepare phase includes a user assessment that:
- Flags accounts with invalid or missing email addresses
- Identifies duplicate accounts
- Prompts you to mark email domains as trusted or untrusted
Permission schemes migrate with projects, but because Cloud uses a different permission model, some configurations may need review post-migration. Global permissions, project roles, and group memberships all transfer, but always validate them after migration as part of your post-migration checklist.
⚠️ Tip: Run the user assessment early in the process. Resolving invalid accounts takes time, especially in large organizations with hundreds of deactivated or legacy accounts.
Q8. Is there a risk of data loss during migration?
Data loss during Jira Cloud migration is rare when you follow Atlassian’s recommended process, but it’s not impossible if migration is rushed or poorly planned. The most common data loss scenarios are:
- Changes made after the migration snapshot – any issue updates, comments, or project changes made in Data Center after the migration begins won’t transfer automatically
- Unsupported app data – if an app doesn’t support JCMA or its Cloud version isn’t installed first, that app’s data won’t migrate
- Invalid user accounts – data owned by users that can’t be migrated may become orphaned
- Skipped projects or custom fields – partial migrations that leave out Jira data can break project configurations and app functionality
The best protection against data loss is thorough preparation: audit your data first, run a test migration on a sandbox environment, and validate results before going to production. Always keep your Data Center instance read-accessible until you’ve fully confirmed the Cloud migration is complete.
Q9. What are the biggest risks of Jira Cloud migration, and how do you avoid them?
App incompatibility discovered late. Some Data Center apps have no Cloud equivalent, or the Cloud version works differently. Solution: Complete the app assessment in JCMA at least 8-12 weeks before your migration date to allow time for finding alternatives.
User chaos post-migration. Broken permissions, missing assignees, and inaccessible projects often trace back to poor user validation. Solution: Run and resolve the JCMA user assessment in the Prepare phase, don’t skip it.
Underestimating scope. Teams that treat migration as a simple export-import often discover mid-process that it’s a multi-month project. Solution: Plan realistically. Large organizations should budget 6-12 months for a well-managed migration.
Q10. What are the best practices for a successful Jira Cloud migration?
Start early. The 2029 deadline sounds distant. It isn’t, for large organizations, migration can take 12-18 months when done properly. Start planning now.
Audit before you migrate. Clean up your Data Center instance first: remove inactive users, archive obsolete projects, consolidate duplicate custom fields, and delete unused workflows. A smaller, cleaner instance migrates faster and with fewer errors.
Validate systematically after migration. Don’t assume it worked, check projects, users, permissions, boards, filters, app data, and automations against a pre-migration baseline.
👉 Start your migration planning with Atlassian’s official Cloud Migration Guide.
If you need help or want to ask questions, please contact SaaSJet Support or email us at [email protected]
For official Atlassian resources, start here:
