Migration planning guide

The Jira Migration Gotchas That Lock Teams In

Moving your issues is the easy part. What actually traps teams is everything wrapped around them — the add-on data with no export path, the scripts nobody documented, the structures no other tool has. Here's the honest map, whatever tool you're moving to.

New here? Start with Chapter 1: when your own renewal quote actually arrives — it's the date that forces this decision, not 2029.

Take the 2-minute lock-in audit

3,000+

Atlassian Marketplace

Marketplace apps, many storing data outside Jira

3–7

each a migration question

Apps a typical instance actually runs

1,000

per export, no history

Issue cap on a native CSV export

~2 min

free audit below

Time to find out if you're trapped

“Can We Export Our Data?” Is the Wrong Question

The answer to that question is always technically yes — issues, pages, and users can be exported from any Jira instance, and every serious destination has an importer. If that were the whole story, no one would feel trapped.

The real questions are the ones sales decks skip: Which of your data lives in apps instead of Jira? Which behavior is encoded in scripts and rules that can't export at all? Which of your structures — portfolio hierarchies, customer portals, SLA clocks — simply don't exist in the same shape anywhere else? Those answers decide whether your migration is a project or a rescue operation. The audit below asks exactly those questions.

The Lock-In Estimator

Answer what applies — skip what doesn't (unanswered counts as “no”). You'll get a lock-in tier and a personalized list of your specific gotchas, worst first. No email required, nothing leaves your browser.

App-locked data

Data that lives inside Marketplace apps, outside Jira's own tables.

Which of these hold data your team can't afford to lose?

Select all that apply — skip any you don't use.

Custom logic

Rules and queries that would be rebuilt from scratch, not migrated.

Do ScriptRunner or JMWE scripts run in your workflows?

Groovy scripts, scripted fields, listeners, workflow extensions

Does your process depend on Automation for Jira rules?

Auto-assignment, transitions, notifications, cross-project syncing

Do your workflows use custom conditions, validators, or post-functions?

Transition gates, required-field enforcement, automatic side effects

Do teams rely on saved JQL filters and dashboards day to day?

Board filters, filter subscriptions, shared dashboards

Planning structures

Constructs that may have no equivalent in the destination.

Do any of these shape your roadmap or portfolio planning?

Hierarchy above epics, cross-project plans, Gantt views

Do you run Jira Service Management portals, SLAs, or queues?

Customer-facing portals, email request channels, SLA timers

Data fidelity

What you need to survive the move intact.

Do you need full issue history preserved (audit or compliance)?

Change history, transition logs, original authorship and timestamps

Would you be migrating while sprints are mid-flight?

Active sprints don't migrate — issues land in the backlog

Connected tools

Everything wired into Jira from the outside.

Which of these are wired into your Jira?

Select all that apply.

Scale & sprawl

The multipliers on everything above.

Roughly how many custom fields does your instance have?

Find it under Settings → Issues → Custom fields

How many Marketplace apps are installed?

Find it under Settings → Apps → Manage apps

Runs entirely in your browser — nothing you select is sent anywhere.

Data That Lives in Apps, Not in Jira

This is the sharpest form of lock-in, and the least visible until you try to leave. Marketplace apps routinely store their data in their own structures — outside the Jira tables that export tooling reads. The app worked so well you forgot it was a separate system. Its data didn't.

Zephyr / Xray / test management

Test cases, test runs, executions, and requirement traceability are stored in app-side data structures. Native migration tooling ignores them entirely, and there's no standard format another platform ingests. Years of QA history can simply have nowhere to go.

Tempo

Raw worklog hours sync to Jira issues, but approvals, billing rates, accounts, and team structures are Tempo's own data. If you invoice from Tempo, your revenue chain of record lives inside a Jira add-on.

Assets / Insight (CMDB)

Object schemas, attributes, and every ticket-to-object reference form a database inside Jira. Tickets pointing at CMDB objects lose their meaning when the objects can't follow.

eazyBI

Report definitions, calculated members, and dashboards are written against Jira's data model. None of it ports — every report is a rebuild against whatever reporting layer comes next.

Even Atlassian's own migration tooling doesn't move app data by default — vendors each maintain their own migration paths of varying quality, and that's for moving between Jira instances. Moving to a different platform entirely means the vendor's API and export tools are all you have. Audit this first: it's the part of your instance where waiting actively makes things worse.

Check Your Own App Inventory

The Marketplace has 3,000+ apps; these are the ones instances most commonly run. Check yours — the aggregate is often a better difficulty signal than any single answer above, because each app is a separate migration decision someone has to make. (This checklist is informational and doesn't change your audit score — several of these apps are already covered by the audit's questions.)

Data locked inRebuild from scratchRewire on the other sideLow risk

Test management

Time tracking & billing

Planning & portfolio

Reporting & analytics

Asset management

Scripting & workflow automation

Forms, fields & checklists

Sync & integrations

Utilities & diagrams

0 data locked in0 rebuild from scratch0 rewire on the other side0 low risk

Nothing checked yet.

Few instances run none of these — check what you recognize, or confirm against Settings → Apps → Manage apps.

If Compliance Is Routing You to Isolated Cloud, Run the Inventory Twice

Regulated buyers who can't sit in a shared, multi-tenant cloud have an Atlassian answer: Isolated Cloud, a single-tenant, dedicated-infrastructure deployment that Atlassian's Tiffany To announced on April 9, 2025 alongside Government Cloud, covering Jira, Jira Service Management, and Confluence. It's a genuine capability, not a marketing label — dedicated compute, storage, and networking, isolated from other customers' instances.

What it doesn't come with is your existing app portfolio. Isolated Cloud only runs apps built on Forge, Atlassian's newer app framework. Shin Nagasada, CEO of the Atlassian Marketplace vendor DevSamurai, put the gap in writing on August 24, 2026: “Apps built on the older framework, which still accounts for a great deal of Marketplace revenue, are not eligible.” That's his characterization of how much of the Marketplace runs on the older Connect framework, not an Atlassian-published figure — there is no percentage to cite, and none should be inferred from it. Eligible apps also have to meet the “Runs on Atlassian” standard: customer data stays inside Atlassian's own infrastructure with no external egress unless a customer explicitly approves it, and the vendor completes security documentation and a compliance review before the app is allowed on.

On cost, Nagasada offers a warning rather than a number: “premium pricing will slow deals down.” No figure is published anywhere — Atlassian's own announcement gives neither pricing nor a minimum seat count for Isolated Cloud. Budget for the unknown, not for a specific premium.

The three-column exercise: run it against your own app list

For every app in the inventory you built above, sort it into one of three columns. Check the app's Atlassian Marketplace listing for a “Built on Forge” or “Runs on Atlassian” badge before assuming it qualifies — vendor marketing about “cloud support” isn't the same claim.

Your app	Works on multi-tenant Cloud	Works on Isolated Cloud	Works on neither
e.g. App A	✓ already running there	Forge + Runs on Atlassian? ___	If neither column fits →
e.g. App B	✓ / ✗	✓ / ✗	replace, rebuild, or retire
… your next app …

The finding here is a method, not a verdict: the sovereignty option narrows your app surface, so price the replacements before you price the platform. If a compliance team already chose Isolated Cloud on your behalf, this is the arithmetic that comes next — and it's worth doing before, not after, the deployment decision is final.

Logic You'll Rebuild From Scratch

Nothing in this category is data you lose — it's behavior you re-create. The cost isn't the rebuild itself; it's the archaeology of finding out what the current instance actually does before you can rebuild any of it.

ScriptRunner and JMWE scripts

Groovy scripts and workflow extensions encode business rules that exist nowhere else — frequently undocumented, frequently written by someone who's left. They can't be migrated, only re-implemented, and the audit to find out what they all do is itself a project.

Automation for Jira rules

Every trigger, condition, and action is written against Jira's model. Rules are faster to recreate than scripts — but only after someone documents what each one is supposed to do, and instances routinely accumulate hundreds.

Workflow conditions, validators, and post-functions

Statuses and transitions map to most destinations. The behaviors bolted onto them — transition gates, enforced fields, automatic side effects — don't. Each one is either rebuilt or becomes a process change.

Saved JQL filters and dashboards

JQL is proprietary. Every saved filter, board filter, subscription, and dashboard gadget is a small program in a language the next tool doesn't speak. The twenty that matter get translated; the long tail dies.

The honest upside: most instances carry substantial dead logic — scripts that fire on nothing, rules nobody remembers, filters with no viewers. A migration audit is the first time in years anyone looks, and a meaningful fraction gets retired instead of rebuilt.

Structures With No Equivalent Elsewhere

Some of what you built in Jira isn't data or logic — it's shape. And shape is what other platforms are least likely to replicate one-for-one.

Portfolio hierarchies & cross-project plans

Advanced Roadmaps, BigPicture, and Structure all let you build initiative→epic→story hierarchies, capacity views, and Gantt plans above Jira's native model. Those constructs belong to the planning app, not to your issues. Destinations have different — or no — native equivalents, so the planning layer is a process redesign, not a data transfer.

JSM portals, SLAs, and queues

Service management is the hardest single thing to move: customer portals have external users who aren't in your org, email channels feed requests in, and SLA clocks are running right now. SLA history generally can't migrate at all — snapshot your compliance reports before any cutover, because that record won't follow you.

What Gets Lost Even When Migration “Works”

Suppose everything above goes perfectly. A successful migration still isn't a copy — these losses are structural, and the teams they hurt are the ones who discover them afterward.

Issue history and transitions
Native Jira exports don't include change history. CSV export drops comments, attachments, and history, and caps at 1,000 issues. Third-party tooling preserves more — but imported items often carry new timestamps and authorship, which matters if audit or compliance is why you wanted history in the first place.
Active sprints and velocity history
In-flight sprints don't survive: issues land in the destination backlog, and burndown, scope-change history, and velocity metrics reset to zero. Cut over at a sprint boundary and archive the reports first.
Permission and notification schemes
Years of accumulated who-can-see-what and who-gets-told-what don't map onto another tool's model. Most teams rebuild simpler — which is usually an improvement, but it's a decision someone has to consciously make, not a default.

The Coupling You Forgot About

Jira's deepest lock-in isn't in Jira — it's in everything that quietly points at it.

Confluence pages embedding Jira macros

Issue macros, chart macros, and roadmap embeds render live from Jira. Leave, and those regions become broken placeholders across your knowledge base — even if Confluence itself stays.

Dev-panel links and smart commits

Years of commit messages reference issue keys like PROJ-1234. The live links die with the instance. Preserving old keys as a searchable field in the destination keeps that history traceable.

Chat and CRM integrations

Slack and Teams notification routing, ticket-from-message shortcuts, Salesforce sync — each is built against Jira's APIs, and each needs a destination equivalent or a workflow change.

SSO and directory sync

Identity flowing through Crowd or Atlassian Access means every group-based permission has to be remapped. Stand up the destination's SSO against the same IdP before importing, so usernames reconcile.

Sprawl: the Multiplier on Everything Above

None of these is a blocker by itself. What sprawl does is multiply the cost of every category above — more fields to map, more apps to audit, more projects to validate. It's also the one gotcha that's entirely self-inflicted, which means it's the one you can start fixing before you migrate anywhere.

Custom fields

Every field is a mapping decision: migrate, merge, or drop. Past ~200, sprawl becomes its own project phase — duplicate fields, contexts nobody understands, screens that differ per project.

Marketplace apps

Each installed app is a question — does it hold data, does anything depend on it, does the destination need an equivalent? Typical instances run 3–7; heavy ones run dozens.

Projects

Abandoned projects cost the same to migrate as active ones. An issue-count-per-project audit finds the dead weight — most instances can archive a surprising share instead of moving it.

Pre-migration cleanup isn't optional overhead — every consultant guide says the same thing: migrating unnecessary data raises cost, risk, and complexity, and cleanup done before the move pays for itself during it.

Know How Tangled You Are. Then Put Numbers on It.

The estimator above tells you what kind of migration you're facing. The sizing tool tells you what it's worth — your actual Atlassian footprint, side by side with what you'd pay elsewhere.

Size My Instance

Sources

Compiled August 2026 from Atlassian's documentation and community forums, migration-vendor guides, and app-vendor migration documentation. Every instance is different — the estimator above is a planning aid, not a substitute for auditing your own instance before committing to a migration plan.