Cloud does not solve Jira complexity. It simply gives it a new home.
The organisations that get the most value from Cloud are usually the ones that simplify before they migrate, not afterwards.
Most Jira Data Center migrations do not fail because data gets lost in transit. They fail because everything that was already wrong with the old environment gets carried straight into Cloud – dead scripts, unused apps, years of permission sprawl,
duplicated or outdated workflows that no longer reflect how teams actually work, and unnecessary configuration built up over years of change.
With Atlassian Data Center reaching end of life on 28 March 2029, the organisations that struggle will not always be the ones that migrate too late. They will often be the ones that migrate on schedule without first deciding what is actually worth taking with them, what should be retired and which opportunities Cloud creates to simplify, standardise and modernise the way they work.
Cloud migration is one of the few opportunities organisations get to simplify a Jira estate without disrupting day-to-day delivery. Treating it as a technical exercise alone wastes that opportunity.
This article sets out how to plan a Jira Data Center to Cloud migration that leaves the mess behind instead of relocating it. If our broader article, Atlassian Cloud Migration Checklist for Jira, Confluence and Bitbucket helped you understand the overall migration route, this article goes narrower on purpose – Jira only, Data Center only and focused on the planning decisions that determine whether the move actually improves the estate.
If you are still deciding whether Cloud is the right destination, start with our article Atlassian Data Center vs Cloud: What UK Teams Need to Know. Everything below assumes that decision has already been made.
Why Jira Data Center migrations go wrong
The Jira Cloud Migration Assistant is good at what it is built for – moving projects, issues, workflows, users and groups into Cloud without overwriting existing Cloud data. That part of the migration is rarely where the biggest problems sit.
The problems sit in everything the migration assistant cannot decide for you. Some data, configurations and behaviours either need manual handling, depend on app support or require separate validation. Marketplace app data, custom fields, permissions, mail handlers, dashboards, filters, boards, automation rules and other configuration items all need careful review.
That is not a flaw in the tooling. It is a sensible boundary. The migration assistant moves what can be moved safely. It does not decide whether something should be moved at all.
For Jira Data Center estates that have been running for years, that distinction matters. The estate may contain Marketplace apps that no longer have a clear owner, Groovy scripts and automations built around outdated assumptions, workflows that reflect historic team structures, permissions that have expanded without review, inactive users, invalid email addresses, archived projects and boards that depend on fields, roles or groups that no longer make sense.
Migration tooling does not distinguish between valuable configuration and accumulated technical debt. It simply moves what it is told to move.
The Data Center deadline you’re actually working to
The 2029 deadline matters, but it is not the only date in the plan. Atlassian’s Data Center end-of-life timeline has three key milestones:
| Date |
What happens |
|---|---|
| 30 March 2026 | New customers can no longer buy Data Center subscriptions or Marketplace apps |
| 30 March 2028 | Existing customers’ last opportunity to buy new Data Center subscriptions, apps or expansions |
| 28 March 2029, 23:59 PST | Data Center reaches full end of life. Affected products and Marketplace apps expire and become read-only |
One exception matters. Bitbucket Data Center is not part of this same timeline. Atlassian has confirmed that Bitbucket Data Center will move to a Hybrid License model instead. That means organisations running Jira, Confluence and Bitbucket on Data Center may not be working to the same migration timeline across every Atlassian product.
For Jira, however, the message is clear. The deadline is now a business constraint, not just a technical one. Waiting until 2028 or 2029 turns the migration into a forced move. Starting earlier gives organisations time to simplify the estate, reduce unnecessary complexity and arrive in Cloud with a cleaner, more supportable platform.
Start with an audit, not the migration assistant
A Jira Data Center to Cloud migration should start with an estate audit, not a technical export, tooling workshop or cutover plan. This is typically led by the Head of Platform and Tools, with input from engineering, security, compliance, delivery and finance. It should be treated as a distinct workstream with its own owner, not as a subtask hidden within the migration project.
The audit should answer one central question. What should move, what should change and what should be retired before Cloud? Everything else in the migration depends on answering that question well.
| Area |
What to check |
Decision needed |
|---|---|---|
| Marketplace apps | Installed apps, usage, Cloud equivalents, migration paths and owners | Keep, replace, rebuild or retire |
| Automations and scripts | Custom scripts, listeners, validators, post-functions, integrations and API dependencies | Rewrite, simplify, replace or remove |
| Projects and boards | Active projects, archived projects, duplicate boards, old delivery models and unused filters | Migrate, archive or consolidate |
| Users and permissions | Groups, roles, inactive accounts, admin rights, invalid email addresses and duplicate identities | Clean, merge, simplify or remap |
| Workflows and fields | Custom workflows, issue types, statuses, schemes, custom fields and whether workflows still reflect current ways of working, including DevOps practices | Preserve, simplify or redesign |
The Jira Cloud Migration Assistant can help surface some of this information, particularly around app assessment, but it is not a substitute for an estate review. For organisations that want this carried out as a structured exercise rather than assembled from scratch, Catapult CX’s Atlassian consulting services are built around exactly this kind of review and focus on app sprawl, licensing, permissions, workflows, governance, ways of working and migration readiness.
Unlike consultancies that focus solely on migration, Catapult CX combines enterprise delivery experience with a Build–Operate–Transfer (BOT) model that embeds improved practices before transitioning ownership back to the client.
On past engagements, this type of review has reduced external audit preparation time by 20%, identified more than £100,000 in annual savings from retiring redundant apps and trials and eliminated misconfigured IDAM roles across a 12,000-user environment.
The commercial point is simple. Every unnecessary app, workflow, permission and script you migrate becomes future Cloud administration, support cost and operational complexity. Do not pay to migrate waste.
What should a Jira Data Center to Cloud migration plan include?
A Jira Data Center to Cloud migration plan should include more than a technical migration window. At a minimum, it should cover migration scope, app and integration decisions, workflow and field cleanup, user and permission mapping, automation refactoring, SSO and SCIM requirements, test migration, cutover sequencing, recovery and contingency planning, and post-migration validation.
A good plan should also make clear who owns each decision, what needs to be completed before testing and what must be fixed before production cutover. This is where many migrations become expensive, not because the migration itself is technically difficult, but because ownership is unclear and critical decisions are left until the project is already under time pressure.
The plan should also separate migration from modernisation. Migration moves data into Cloud. Modernisation reduces complexity, governance risk and operating cost before that happens. Organisations that separate those two conversations almost always end up with a simpler, more supportable Cloud environment, because most of the long-term value comes from what is improved before migration rather than what is moved during it.
What not to migrate
One of the most valuable planning decisions is deciding what not to take. Jira estates grow slowly and messily. Every new delivery team, acquisition, programme, vendor, workflow experiment and temporary permission request leaves residue.
Cloud migration is one of the best opportunities to challenge that residue. Every item that is retired before migration is one less item to support, govern and pay for afterwards.
| Do not automatically migrate |
Why |
|---|---|
| Dead projects |
They add migration effort, search clutter and future admin overhead |
| Unused Marketplace apps |
They carry cost and support risk into Cloud |
| Broken or duplicated workflows |
They recreate delivery friction in the new environment |
| Stale users and groups |
They create identity, licensing and audit problems |
| Old custom fields |
They slow reporting and complicate schemes |
| Customisations that support outdated or team-specific ways of working |
They become silent operational risk after migration. They increase complexity and may no longer reflect how the organisation wants teams to operate in Cloud. |
The default should not be ‘move everything and tidy it later.’ Later rarely happens. If the estate is too complex to clean fully before migration, prioritise the highest-risk areas first. These include apps, permissions, identity, scripts and critical delivery workflows. The goal is not to migrate everything successfully. It is to migrate only what still creates value.
Plan for regulated-sector requirements early
For regulated organisations, this migration is not purely a technical project. Governance, security and operational resilience need to be considered from the outset, not added once the migration is underway.
The FCA’s operational resilience rules require firms to identify important business services, understand their supporting dependencies and remain accountable for resilience, even where third parties are involved. A Jira migration may not be customer-facing, but Jira often supports the delivery, change, incident and engineering processes behind those important business services.
For government organisations, the same principle applies through a different lens. The Government Cloud First policy expects public sector organisations to consider public cloud first when procuring new or existing services. Security also needs to be designed in from the outset, with the Secure by Design approach embedding security and governance throughout the lifecycle of digital services and technical infrastructure.
None of this changes how the migration assistant works. It changes what ‘done’ means. A technically successful migration that has not addressed governance, identity, security and operational resilience is not truly complete. This is the kind of context Catapult CX builds into Atlassian consulting and migration planning for regulated organisations.
Where Isolated Cloud fits
Atlassian Isolated Cloud is relevant for large enterprises and regulated organisations that need more control than standard multi-tenant Cloud. Atlassian describes Isolated Cloud as an Atlassian-managed cloud environment with dedicated infrastructure for organisations with strict data isolation requirements.
That is a meaningful step up in isolation, but it should not be treated as a complete answer to every sovereignty, compliance or jurisdictional concern. Regional data placement and dedicated infrastructure reduce risk, but they do not remove the need to review supplier control, contractual obligations, cross-border processing, support access, operational resilience and regulatory requirements.
For some organisations, Isolated Cloud may be the right destination. For others, it may form just one part of a broader compliance and governance strategy. The decision should be driven by regulatory, contractual and operational requirements rather than infrastructure preference alone. Either way, it belongs in the migration decision model, not as an assumption added at the end.
Building the plan. Scope, users, apps, cutover
Once the audit is complete, the migration plan can be built properly. For a Head of Engineering, the priority is maintaining delivery while the estate is prepared in the background. For a Head of Platform and Tools, it is reducing migration risk and creating a cleaner operating model. For a CTO, programme or delivery manager, it is ensuring the migration reduces operational complexity rather than simply changing the hosting model.
A practical Jira Data Center to Cloud migration plan should move through five stages.
| Stage |
Main output |
|---|---|
| 1. Estate review | Inventory of apps, scripts, workflows, users, permissions, projects and dependencies |
| 2. Migration design and refinement | Decisions on what moves, what changes, what retires and what needs rebuilding, refined as the migration progresses |
| 3. Iterative test migrations | Migration approach validated and refined through repeated testing in sandbox or test environments |
| 4. Production cutover | Sequenced migration with communication, support and rollback planning |
| 5. Post-migration optimisation | Validation, defect fixing, user support and governance cleanup |
The key is sequencing. Do not run the migration assistant first and then discover what broke. Use the audit to decide what the migration assistant should move.
For the complete cross-product checklist covering Jira, Confluence and Bitbucket, see our Atlassian Cloud Migration Checklist. For organisations dealing with legacy Jira dependency issues, Six Top Tips for a Smooth Jira Migration also covers several considerations that remain relevant when planning a move to Cloud.
Questions to ask a migration partner
If you are evaluating outside help, these questions separate a genuine migration partner from someone who is simply going to run the migration assistant.
- How do you handle Marketplace apps with no Cloud equivalent?
- How do you assess app usage before migration?
- How do you handle Groovy scripts and custom automations?
- How do you validate permissions, identity, SSO and SCIM?
- How do you account for FCA, PRA, government or security obligations?
- How will you help us reduce complexity before migration rather than simply migrate it?
- What happens after cutover?
- What do you expect us to own?
An accredited Atlassian Solution Partner should be able to answer these questions confidently and explain the reasoning behind their recommendations. Migration expertise is not just about running the tooling. It is about helping organisations arrive in Cloud with a simpler, better-governed and more supportable Jira environment.
See our guide on why using an Atlassian Solution Partner matters for more on what an experienced partner should bring beyond tool administration.
The migration is the opportunity
A Jira Data Center to Cloud migration should not be treated as a response to the 2029 deadline. It is an opportunity to simplify the operating model around Jira by reducing app sprawl, cleaning permissions, improving identity control, retiring dead projects, rebuilding only the automations that still add value, and creating a platform that better supports modern engineering practices and ways of working.
If the migration preserves every dead workflow, unused app and unclear permission model, the organisation has paid for migration without achieving modernisation. Cloud will not fix Jira complexity by itself. The planning work has to do that.
Before you build the migration plan, review the estate. Catapult CX’s Atlassian consulting services help organisations identify app sprawl, workflow debt, permission risk and licence waste before they become Cloud migration problems and unnecessary long-term operational cost.
FAQ
Is Jira Data Center going away?
Yes. Atlassian has confirmed that impacted Data Center products will reach end of life on 28 March 2029 at 23:59 PST. After that date, affected products and supported Marketplace apps become read-only. Organisations still using Jira Data Center should already be planning migration and estate rationalisation.
What is the Jira Data Center end-of-life date?
The full end-of-life date is 28 March 2029 at 23:59 PST. Two earlier milestones are also important – 30 March 2026, when new customers can no longer purchase Data Center subscriptions or Marketplace apps and 30 March 2028, when existing customers have their final opportunity to buy new Data Center subscriptions, apps or expansions.
When should we start planning a Jira Data Center migration?
The best time to start is well before the 2029 deadline. Early planning gives organisations time to review apps, simplify workflows, clean permissions, retire redundant projects and test migrations properly, rather than treating the move as a time-critical infrastructure project.
What should a Jira Data Center to Cloud migration plan include?
A Jira Data Center to Cloud migration plan should include migration scope, app and integration assessment, workflow and field cleanup, user and permission mapping, automation refactoring, SSO and SCIM planning, test migration, production cutover, rollback planning and post-migration validation. It should also define ownership, governance and decision points throughout the project.
Should we clean Jira before migrating to Cloud?
Yes. Cleaning Jira before migration reduces cost, complexity and operational risk. Dead projects, unused Marketplace apps, stale users, broken workflows, redundant custom fields and unowned scripts should all be reviewed before they are migrated into Cloud.
Can the Jira Cloud Migration Assistant migrate everything?
No. The Jira Cloud Migration Assistant supports many migration tasks, but some Marketplace app data, customisations, configurations, dashboards, filters, permissions, mail handlers and automations may require manual handling, alternative tooling or post-migration validation. The migration assistant moves supported data; it does not decide what should be migrated.
Do all Jira Marketplace apps work in Cloud?
No. Some Marketplace apps have direct Cloud equivalents, some require alternative solutions and others may not be supported in Cloud at all. Every app should be assessed individually before migration to determine whether it should be migrated, replaced, rebuilt or retired.
What is the biggest mistake organisations make during a Jira Cloud migration?
The biggest mistake is treating migration as a technical data transfer rather than an opportunity to simplify the Jira estate. Migrating unused apps, outdated workflows, excessive permissions and legacy configurations into Cloud recreates the same operational complexity in a new environment.
How long does a Jira Data Center to Cloud migration take?
The migration window itself may be relatively short, but planning, estate assessment, application review, testing and post-migration validation often take much longer. The overall timescale depends less on the volume of Jira data than on the complexity of the existing environment.
Should we migrate Jira Data Center to Atlassian Cloud or Isolated Cloud?
The right destination depends on regulatory, contractual, operational and security requirements. Standard Atlassian Cloud is suitable for many organisations, while Atlassian Isolated Cloud may be appropriate where greater infrastructure isolation is required. The decision should be made during migration planning rather than after technical design has begun.
