Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Your Atlassian migration deadline depends first on whether you run Server or Data Center. Server support ended on February 15, 2024 PT; for impacted Data Center products, end of life is March 28, 2029 at 23:59 PST, with a phased wind-down that began March 30, 2026. Identify your deployment, confirm the product-specific dates and destination requirements, then work backward from your deadline to assess apps and users, test the migration, and schedule a protected cutover.

Which Atlassian deadline applies to you?

Start with the deployment type shown in your Atlassian product and licensing records—not the product name alone. Jira, Confluence, Bitbucket, and other Atlassian products have had Server and Data Center editions, and the applicable support schedule differs. Atlassian’s Server End of Support FAQ and Data Center End of Life announcement describe the relevant schedules.

Deployment or phase Date and what it means
Atlassian Server Support ended February 15, 2024 PT. Atlassian no longer provides support or bug fixes for Server products and apps. The affected list includes Jira Software, Jira Core, Jira Service Management, Confluence, Bitbucket, Crowd, Bamboo, Atlassian-built Server apps, and Marketplace apps for Server. This date has passed.
Impacted Data Center products: wind-down begins March 30, 2026. New customers can no longer buy new Data Center subscriptions or new Marketplace Data Center apps. Existing customers may continue buying subscriptions, apps, and expansions until March 30, 2028 at 23:59 PST.
Impacted Data Center products: end of life March 28, 2029 at 23:59 PST. Subscriptions and associated Marketplace apps expire and become read-only. Atlassian says technical support, critical-vulnerability security bug fixes, and connectors to Cloud continue through this date.
Bitbucket Data Center Atlassian says Bitbucket Data Center will not reach end of life under this announcement. Existing customers will gain access to a Bitbucket Hybrid License for Data Center and Cloud. Confirm the terms applicable to your organization with Atlassian.

The Data Center wind-down is phased: March 30, 2026 was not the date all support ended. For impacted products, the announced end-of-life date remains March 28, 2029. Certain Data Center customers may receive extended maintenance after that date by exception; do not assume eligibility or availability without confirming directly with Atlassian.

Choose a destination that meets your requirements

Atlassian recommends Cloud for most Server customers and identifies Cloud or a Data Center upgrade as supported-platform paths for Server customers. For impacted Data Center products, Cloud is the announced ongoing destination. A move should be based on the requirements of your particular deployment, not just the calendar.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Support horizon: Map your current edition to the dates above, and verify the current product-specific support position before committing to a plan.
  • Features, apps, and integrations: Check that required functionality, Marketplace apps, customizations, and connected systems will work in the destination. App availability or a substitute may affect both the decision and the schedule.
  • Security, residency, and policy: Compare the specific Cloud environment or self-managed option against your security, data-residency, contractual, and regulatory requirements. Government customers should verify the authorization status and timing of the specific environment they need; Atlassian notes that government authorization timing is not under its control.
  • Operations and outage tolerance: Consider how your organization will manage accounts, administration, upgrades, integrations, and user support after the move, along with how much disruption users can tolerate during migration.

Record the reason for the selected destination and any unresolved requirements. If a requirement cannot yet be confirmed, treat it as a decision dependency rather than assuming it will be satisfied later.

How much time should you allow?

Atlassian published an average of nine months from assessment through launch in a February 14, 2023 article, How to prepare for the end of server. That is historical planning context, not a current measurement or a promised duration for an individual project. Your schedule depends on the deployment, products, user base, app and integration readiness, customizations, policy requirements, test results, and stakeholder readiness.

Build a plan from the work and evidence you have: inventory and requirements first, then migration preparation, rehearsal and user acceptance, remediation, production cutover, and post-move support. Put decision gates between those phases. Do not set the production date until the relevant compatibility issues have been addressed and the rehearsal results support it.

Build the migration plan around your own deadline

  1. Establish the facts. Confirm each product’s deployment type and version, license and subscription details, user counts, data footprint, customizations, integrations, and contractual or regulatory constraints. Record which Data Center products are impacted and map your work against the end-of-life date and earlier purchase milestones. If you run Server, its support deadline has passed; prioritize a supported-platform plan rather than treating the former date as a future target.
  2. Choose and validate the destination. Assess Cloud and any applicable self-managed path against the requirements listed above. Verify product-specific functionality, app compatibility, integrations, security, residency, and operating constraints with the relevant vendors and administrators before freezing the design.
  3. Inventory apps and users. Use Atlassian’s migration resources for user management, app assessment, migration methods, downtime planning, and product-specific checklists. Confirm which apps are needed, whether a compatible destination version or replacement is available, and how user identities and email addresses will be handled.
  4. Confirm tool and source compatibility. Check that your source product version is compatible with the migration tooling and method you intend to use. Review product-specific prerequisites before scheduling a rehearsal; do not assume one assistant covers every Atlassian product.
  5. Rehearse and test. Create a test environment, back up the source, run the applicable pre-migration checks, and perform a trial migration. Have representative users complete user acceptance tests. Log errors and gaps, resolve them, and rerun checks or rehearsals as needed. Choose the production date based on what the tests demonstrate, not a hoped-for duration.
  6. Schedule a staffed production window. Choose a low-activity period, allow contingency time, and ensure the people responsible for migration, systems, apps, communications, and business validation are available. Atlassian advises customers migrating more than 1,000 users to tell their Cloud Migration Manager the production date at least a month ahead. Notify users and support teams about timing and any actions to avoid while the migration is underway.
  7. Protect the cutover and validate afterward. Use a runbook with named owners, checkpoints, escalation contacts, and post-migration checks. Take a final backup, control source-side changes during the migration, monitor progress, and provide a channel for user issues. Atlassian’s checklist recommends temporarily limiting data creation, modification, and configuration changes—or briefly making the source read-only—to reduce changes during the migration event.

Atlassian’s Cloud Migration Checklist (2024 PDF) covers preparation, testing, downtime planning, and cutover considerations. Atlassian’s migration resources also point to Solution Partners for planning and hands-on support, and list FastShift as a dedicated-support migration program. Check current eligibility and terms directly with Atlassian or a partner.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What Jira Cloud Migration Assistant can—and cannot—tell you

Atlassian describes Jira Cloud Migration Assistant as a tool for moving Jira from Server or Data Center to Cloud. It can assess Marketplace apps and user email addresses, review domains, support selective or full migration, and provide pre-migration checks, reports, and error logs. Atlassian’s documentation says migration data is stored for 14 days from migration creation.

The assistant’s listed coverage includes Jira Core, Jira Software, Jira Service Management, and certain Advanced Roadmaps plans. Listed data includes projects and issues, users and groups, boards and sprints, workflows and filters, and Assets. These capabilities do not establish that every app, customization, integration, or dataset in a particular instance will migrate without remediation; review the checks and test results for your instance.

Do not treat the Jira assistant as a migration tool for Confluence or Bitbucket. Atlassian provides separate product migration resources and assistants for those products through its migration hub.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.