Systems and records
What doesn't migrate from Jira or Confluence Data Center to Cloud
By SourceX Editorial · Updated
Short answer
Atlassian's migration assistants move most projects, issues, spaces, pages and their history to Cloud, but they commonly leave gaps: data stored by Marketplace apps, app-driven workflow logic and scripts, some instance-wide settings, and user details that do not map cleanly. Archive the Data Center instance in full before cutover and keep that archive restorable.
Key takeaways
- Atlassian publishes what its Jira and Confluence migration assistants do and do not move; check the list for the version you run.
- Marketplace app data migrates only where the app vendor supports a cloud migration path.
- Workflow conditions, validators, post functions and scripts provided by apps often have to be rebuilt in Cloud.
- A full database backup plus the attachments directory, tested by a restore, is the safety net for anything the assistants skip.
What the migration assistants are built to move#
The Jira Cloud Migration Assistant and the Confluence Cloud Migration Assistant are built to move the core of each product: projects, issues, comments, attachments and issue history in Jira; spaces, pages, blog posts, attachments and page history in Confluence; and the users, groups and permissions needed to make them usable.
Atlassian publishes lists of what each assistant migrates and what it does not, and those lists change as the assistants are updated. Read the list for the version you will run, test with a representative project and space, and compare results side by side before planning cutover.
Jira Service Management needs its own pass. Customer accounts, portal settings, queues and service level agreement configuration behave differently from software projects, and customers of a service project are not the same as licensed users, so test those projects separately.
Commonly reported gaps#
The commonly reported gaps cluster around customizations, because the assistants handle standard product data best. Treat the table as a starting list to check against Atlassian's current documentation and your own test migration, not as a definitive inventory.
| Area | Typical gap | What to archive |
|---|---|---|
| Marketplace app data | Moves only where the app vendor offers a cloud migration path | Each app's data export, version and configuration |
| App-provided custom fields | Field types without a cloud equivalent may not carry values | Field definitions and values exported by issue key |
| Workflow logic from apps | Conditions, validators and post functions may be dropped or simplified | Workflow definitions and notes on each transition rule |
| Scripts and automation | Server-side scripts do not run unchanged in Cloud | Script source, triggers and a plain description of each |
| Instance-wide settings | Some global configuration is not moved | Documentation of system settings, schemes and look and feel |
| Users and groups | Directory links, inactive users and users without email need handling | User and group export with memberships and status |
| Confluence macros | User macros and some app macros do not render in Cloud | Macro source and examples of pages that use them |
| Integrations | Application links and tool connections must be rebuilt | A list of every link and integration with its purpose |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
History that breaks quietly after cutover#
History breaks quietly when the data moves but its meaning does not. A transition governed by a post function that no longer exists, a mention of a user who now shows as a former user, or a Confluence page full of unrendered macros has technically migrated and is practically unreadable.
Links are the other weak point. Links from Confluence to Jira, from commits to issues, and from support tickets to engineering work point at old base URLs or old keys until they are remapped. Merging projects during migration changes issue keys, and every outside reference to an old key needs a redirect or a mapping table.
Run a sample check after the test migration: pick old, heavily edited issues and pages, and confirm their history, links and rendering against the Data Center originals.
Archive checklist before cutover#
The archive checklist covers what you would need to answer a question about the old instance after the server is gone. Complete it before the final migration window, while app vendors and the people who built customizations can still be reached.
- Full database backup and the complete shared home directory with attachments
- Confluence space exports for spaces with heavy macro or app use
- A list of installed apps with versions, licenses and vendor contacts
- Data exports from each app that lacks a supported cloud migration
- Workflow, scheme and custom field definitions
- Script and automation source code with a plain description of each
- User and group export with memberships, status and directory source
- Audit logs and application link configuration
- A test restore of the backup on a separate server, documented step by step
Keep the old server, a backup or a neutral archive?#
Keeping the old server, keeping a backup and building a neutral archive serve different needs, and most teams use more than one. The choice turns on how often people will look things up and how long the history must stay readable without Atlassian software.
Do not count on Cloud-side backups to replace the Data Center archive. Atlassian Backup and Restore needs a Premium or Enterprise plan and keeps backups in Atlassian-owned storage for 30 days. The Confluence Cloud Backup manager stores one backup file at a time, keeps the download link for 14 days and skips soft-deleted spaces in the trash. Those tools protect the migrated site going forward; they never held what the migration left behind.
| Option | What it gives you | Watch out for |
|---|---|---|
| Read-only Data Center instance | Full fidelity, familiar screens, app data in place | License, server and security upkeep; meant to be temporary |
| Restorable backup | Everything preserved at low running cost | Needs a matching software version and the skills to restore |
| Neutral archive in JSON or CSV plus files | Readable without Atlassian software | Effort to build; must keep keys, history and links |
| Combination | Short-term access plus long-term readability | A named owner and a retirement date for each part |
Illustrative: a CAD software company retires Data Center#
Illustrative: a fictional CAD software company has run Jira and Confluence Data Center for many years, with a test management app, a scripting app for custom workflow rules and a large body of Confluence design specifications built with app macros. The CTO sets a date to move to Cloud.
The test migration shows that test execution history from the app will not move, several workflow validators disappear, and specification pages render with missing macros. The team exports test runs by issue key, documents each script and rebuilds the critical ones, and exports the affected Confluence spaces in full.
After cutover, the company keeps the Data Center instance read-only for a defined period, then retires it, holding on to a restorable backup and the neutral archive. Product decision records in the old specifications stay readable, which matters when a customer dispute later turns on a design choice made years earlier.
How SourceX views a pre-migration archive#
SourceX views a pre-migration archive as well-timed engineering history, because the period before cutover is when the fullest version of that history still sits in one place. Under the SourceX Enterprise Data Value Framework, issues with complete changelogs, linked specifications and decision records score higher than migrated data with broken links.
A first assessment uses descriptions only: products, years, projects and installed apps. Any package that proceeds follows the SourceX five-step transaction, with the archive kept in company storage and secrets, customer details and personal information removed in Preparation.
Frequently asked questions
Does the Jira migration assistant move issue history?
In general it moves issue history along with issues, but exceptions exist, especially where history depends on app fields or deleted users. Test with older, heavily edited issues and compare their history to Data Center before treating the migrated copy as your only record.
What happens to users who have left the company?
Inactive and deleted users are handled differently from active ones, and their names may show as former or unknown users in Cloud. Export user and group details before migration and map account identifiers to roles so historical activity can still be interpreted.
Can app data be migrated after the cutover?
Sometimes, but it is usually harder. Once the Data Center instance is retired, the app's data lives only in backups, and the vendor's migration path may expect a live server. Export app data and settle each app's plan before cutover.
Should we clean up Jira and Confluence before migrating?
Cleanup reduces migration effort: archiving dead projects, removing unused custom fields and deleting duplicate spaces all help. Archive first, though, because cleanup deletes history permanently. Take the full backup, export anything you plan to remove, and record what was cleaned up and why before the assistants run.
Does Atlassian keep a copy of our Data Center data?
No. Data Center is self-managed, so the server, database and attachments are yours to keep or delete. Atlassian holds only what you migrate to Cloud, which makes your own backup and archive the only record of anything the migration did not move.
How long should we keep the Data Center backup?
Set the period in a written retention schedule that reflects contract, audit, dispute and product needs. Test that the backup restores before relying on it, and record the software version it needs, because restoring into a much newer version can fail.
Sources
- Atlassian Backup and Restore lets admins back up Jira and Confluence data from admin.atlassian.com on demand or on a daily or weekly schedule, requires a Premium or Enterprise plan plus organization admin and app admin permissions, and stores backups in Atlassian-owned storage for 30 days, expiring on the 31st day. Source
- Atlassian states that a Confluence Cloud site backup (Backup manager under Data management) can be up to 30 GB in total size plus 800 GB of attachments, includes attachments only if selected, and does not back up soft-deleted spaces in the trash. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.