How to plan, prepare, and execute a clean transition to Atlassian Cloud
The Atlassian ecosystem is undergoing the most significant transformation in its history. As Atlassian accelerates its cloud-first strategy, the company has officially announced the end-of-life timeline for Jira Data Center. While organizations still have time before support fully ends, the window for planning a successful migration is already open. The earlier you begin preparing, the smoother your transition to Jira Cloud will be.
This guide walks you through the strategic decisions, cleanup steps, technical considerations, and practical workflows needed to ensure a predictable and well-executed migration. Whether you are migrating a full enterprise instance or only selected projects, these recommendations will help you build a stable Cloud environment and minimize downtime during cut-over.
Addendum: Official Atlassian Data Center End-of-Life Timeline
As part of Atlassian’s cloud-first transformation, the company has published a clear, multi-year retirement plan for Data Center products. Understanding these dates is essential for planning your migration strategy:
March 30, 2026, at 23:59 PST
New customers will no longer be able to purchase new Data Center subscriptions or new Marketplace Data Center apps.
March 30, 2028, at 23:59 PST
Existing customers can continue to purchase new Data Center subscriptions, Marketplace apps, and subscription expansions until this date.
March 28, 2029, at 23:59 PST
End of life for all impacted Data Center products.
Subscriptions and Marketplace apps expire on this date, and all Data Center products transition to read-only mode permanently.
Support Commitment During the Wind-Down Period
Atlassian will phase out Data Center support over a three-year transition period (March 30, 2026 → March 28, 2029) to give customers ample time to assess, prepare, test, and migrate.
Until the final EOL date (March 28, 2029), Atlassian will continue providing:
- Technical support
- Security bug fixes for critical vulnerabilities
- Connectors between Atlassian Data Center products and Atlassian Cloud
This ensures that customers can continue operating securely while planning a structured migration.
For the full official announcement and FAQ, see:
Atlassian Data Center End-of-Life Announcement
Start with an Assessment: What Actually Needs to Move?
Before touching any tools, start with a detailed inventory of what lives in your Data Center instance.
Identify which projects must be migrated
Not all projects have to move to Cloud. Use this stage to evaluate:
- Which projects are actively used
- Which projects are outdated or can remain archived in Data Center
- Which projects can be merged or cleaned up before migration
Decide what to do with existing issues (work items)
There are three common strategies:
- Migrate everything
Straightforward, but may balloon migration time and Cloud storage usage. - Migrate only recent work items
For example: move only the last six months of data and leave older issues in a read-only Data Center archive. - Archive issues before migration
Create dedicated Archive projects, then bulk-move older issues there. Migrate only the active issues in the main projects.
If you plan to delete old issues permanently, do so before migration to reduce data volume and improve performance.
Clean Up Filters, Boards, Dashboards, and Automations
Jira instances tend to accumulate clutter over the years. Migrating unnecessary configuration elements increases risk and extends migration time.
Filters and boards
Remove or exclude:
- Filters linked to deleted projects
- Boards are no longer used
- Boards tied to projects you are not migrating
Dashboards and gadgets
Pay special attention to gadgets provided by Marketplace apps. Their migration may depend on the app’s Cloud availability.
Automations
System administrators should:
- Document all existing automations
- Identify which ones must move to Cloud
- Remove or disable unused rules
Since Jira Cloud automation uses a different engine, plan to rebuild selected rules using Cloud-native automation.
Review Users and Access to Optimize Cloud Licensing Costs
Data Center licensing is tier-based; Cloud pricing is per-user. This difference makes user cleanup critical.
Remove or deactivate:
- Former employees
- Users with no active need for Jira access
- Technical accounts no longer in use
This step directly impacts your future Cloud bill.
Evaluate Marketplace Apps and Their Cloud Equivalents
For every app installed in Data Center, ask:
- Does the app have a Cloud version?
- Does it support automated migration?
- Does the Cloud version offer the same features?
Use Jira Cloud Migration Assistant (JCMA)
JCMA helps you assess your apps:
- Automated path: JCMA migrates app data with the rest of the instance
- Install-only: you install the Cloud version; configuration may need manual rebuilding
- No path / Contact vendor: manual migration or app replacement required
Not all apps migrate cleanly. In some cases, Cloud versions differ significantly in features or UI. Treat app migration as its own mini-project.
Verify whether the Cloud platform already provides native features
One crucial step that many teams overlook is evaluating whether an app is still needed once you move to Cloud. Atlassian Cloud includes a wide range of built-in capabilities that were historically available only through Marketplace add-ons on Data Center.
Before you plan to migrate or reinstall a Marketplace app, check whether Jira Cloud already provides the functionality natively. In many cases, Cloud includes:
- Advanced automation
- Improved forms and request types in Jira Service Management
- Enhanced APIs and integrations
- Native asset management (depending on plan)
- New reporting and dashboard options
- Simplified workflow management
- Project-level configurations that previously required extensions
This can significantly reduce complexity and lower your Cloud subscription costs. If Cloud offers a native alternative, the Marketplace app may no longer be required.
Use the Migration as an Opportunity to Rebuild Smarter
Cloud differs from Data Center in several core areas. Preparing Cloud-specific components early – ideally in a sandbox – will dramatically shorten your production cut-over window.
Prepare in advance:
- A new permission model (Cloud has org-level administration and different Global Permissions)
- Updated automation rules
- A revised group structure, especially if using Atlassian Access or SSO
- Recreated dashboards using Cloud gadgets
Document every Cloud configuration with screenshots or step-by-step notes. This becomes your post-migration checklist executed immediately after cut-over.
The Official Atlassian Migration Process
1. Create a Cloud sandbox or Cloud Migration Trial
Atlassian requires a test migration before attempting a production migration.
A Cloud Migration Trial:
- Is free
- Mirrors your Data Center user tier
- Lasts up to the end of your DC subscription (or at least 60 days)
2. Run at least one full test migration
Use this to:
- Validate project behavior
- Test workflows, fields, and attachments
- Confirm app compatibility
- Measure how long the production cut-over will take
Most organizations perform 1–3 test cycles.
3. Prepare for production migration
This includes:
- User cleanup
- App readiness checks
- Project rationalization
- Validating that JCMA detects all data correctly
- Creating full backups
Optionally, you can pre-load some data into Cloud to shorten the final cut-over:
- Users & groups
https://support.atlassian.com/migration/docs/migrate-jira-users-and-groups-in-advance/ - App data (where supported)
https://support.atlassian.com/migration/docs/preload-app-data-before-migration/ - Attachments
https://support.atlassian.com/migration/docs/migrate-jira-attachments-in-advance/
4. Execute the production cut-over
During the migration window:
- Announce system downtime
- Freeze Jira DC
- Run JCMA migration
- Monitor logs until completion
Large instances may require a night or weekend window.
5. Post-migration validation
After Cloud is live:
- Reinstall Cloud apps
- Rebuild dashboards and automations as planned
- Validate permissions and workflows
- Conduct UAT with key users
Atlassian expects each organization to validate its own migrated data.
External Communication Channels: Migrating Email Handlers
Email-to-issue creation works completely differently in Jira Cloud.
How Cloud processes email
- Cloud uses Atlassian-managed addresses or
- Connects to external mailboxes (Microsoft 365 / Google Workspace)
What to prepare before migration
- Create or identify the mailbox Cloud will use
- Pre-configure the channel in Cloud sandbox
- Freeze incoming mail handlers in DC shortly before migration
- After cut-over, reconnect the mailbox to Cloud immediately
- Verify no tickets are stuck in the old inbox
- Forward any leftover messages manually if needed
This ensures zero lost requests and keeps your support teams operational from day one.
Cloud Migration Trial: What You Get and What to Expect
Atlassian offers free Cloud trials specifically designed for migration projects.
Key facts
- Mirrors your DC user tier up to 20,000 users
- No-cost trial
- Intended for testing, not full production workloads
- Limited support and reduced email sending limits
- Expires when your DC license expires (or after 60 days if already expired)
A Cloud trial is the safest way to test migration repeatedly without affecting production.
What Happens to the Jira Data Center Instance After Migration
Once the Cloud environment is fully operational, you have two options:
A. Full decommission
If all tickets have been migrated:
- Keep DC in read-only mode for up to 3 months
- Validate everything with teams
- Decommission once confirmed
B. Keep DC as a long-term archive
If you want ongoing access to legacy projects:
- Set the instance to read-only
- Restrict user access
- Note that DC will continue to function in read-only mode even after the license expires, including beyond March 28, 2029
This makes DC a practical long-term storage solution for historical data.
Updating Customer Access for Jira Service Management Portals
If your customers use JSM portals, communication is critical.
Best practices:
- Send announcements one week before and one day before migration
- Set up a 301 redirect from your old support domain
- Add autoresponders reminding customers of the new portal location
- Forward emails from old inboxes to Cloud
- Add banners in the new Cloud portal
- Update all links on your website
- Issue a final “we’re live” notification once migration is complete
These steps eliminate customer confusion and reduce support load.
Migrating the “Clone Expert for Jira Templates, Epics and Issues” App
Clone Expert relies entirely on Jira’s native issue structures.
It does not maintain its own configuration, requiring migration.
Migration process
- Migrate your Jira instance using JCMA
- Install Clone Expert for Jira Cloud from the Marketplace
- Use the app to clone structures, templates, or work items exactly as you did in Data Center
No data transfer or app-specific migration step is necessary.
Why Clone Expert Still Matters in Jira Cloud
While Jira Cloud offers built-in issue cloning, it is intentionally basic. Many teams initially assume that native cloning will replace the need for Clone Expert, but this is typically not the case. Jira Cloud’s default cloning does not support the advanced use cases that Clone Expert was designed for, including:
- multi-level cloning of epics, stories, and subtasks
- cloning complex templates or reusable project structures
- deep copying of custom fields with mapping
- preserving relationships, dependencies, and hierarchies
- cloning collections of issues in bulk
- reproducing workflow-driven structures at scale
Clone Expert for Jira Cloud continues to provide the full advanced, structure-aware cloning experience used by Data Center customers.
A detailed comparison of native Jira Cloud cloning vs. Clone Expert functionality is available here.
This makes Clone Expert an important component to evaluate during migration planning. Even if Jira Cloud includes native cloning, the functionality is not equivalent, and organizations that depend on robust templating or hierarchical issue creation will still benefit from installing Clone Expert in their Cloud environment.
Handling Templates During Migration
If your Data Center instance includes templates created and cloned with Clone Expert, it is important to consider how these templates will be preserved during the migration. Clone Expert does not store template definitions outside Jira issues, so templates only migrate when the underlying problems migrate.
This becomes especially important if your migration is not a full 1:1 migration of all projects and all work items. For example:
- If you migrate only the last six months of issues
- If you archive older items before migration
- If you selectively migrate only certain projects or components
Then any templates stored as Jira issues but omitted from the migration scope will not appear in Jira Cloud after cut-over.
In such cases, these templates must be recreated manually in the Cloud instance. To avoid losing valuable template structures, ensure that:
- Template issues are included in the migration project scope
- Archive or cleanup activities do not remove template items
- Administrators explicitly validate template locations before finalizing the migration plan
If templates are migrated together with the relevant work items, Clone Expert Cloud will recognize and clone them normally. If they are skipped, manual reconstruction will be required after installation of the Cloud version of the app.
⚠️ Caution: Custom Placeholders Must Be Recreated Manually
If your team uses Custom Placeholders within Clone Expert templates, these configurations will not migrate automatically to Jira Cloud. Unlike Standard Placeholders (which require no additional action), custom-defined placeholders must be manually copied from Data Center and recreated in the Cloud version of the app.
The required steps are straightforward but essential:
- Open each template or issue in Data Center that includes Custom Placeholders
- Copy the placeholder definitions exactly as they appear (1:1)
- After installing Clone Expert in Cloud, recreate the same Custom Placeholders in the corresponding templates
Failing to do this may result in templates producing inconsistent cloning behavior after cut-over.
For this reason, recreating Custom Placeholders must be included in your post-migration manual configuration checklist. Ensuring this step is documented and executed will guarantee that Clone Expert behaves in Cloud exactly as it did in your Data Center environment.
Users who rely exclusively on Standard Placeholders do not need to take any additional action – these work immediately in Cloud once the app is installed.
If you need assistance during the migration or while recreating your templates and Custom Placeholders in Jira Cloud, please submit a request through our Service Desk.
Conclusion
Migrating from Jira Data Center to Jira Cloud is more than a technical exercise – it’s an opportunity to redesign your environment, modernize processes, reduce maintenance burden, and scale with Atlassian’s cloud-first innovation.
By approaching migration systematically – cleaning up your instance, testing thoroughly, assessing Marketplace apps, and preparing Cloud configurations in advance – you set yourself up for a smooth transition with minimal downtime.
As Atlassian Marketplace vendors, we support customers through this transformation, ensuring that their tools, workflows, and extensions continue to deliver value in the cloud.
For more information, go to the official Atlassian migration guide here: Atlassian Cloud Migration Center (Migration Guide)