Jira and Confluence cloud migration: what happens to old projects and spaces

What happens to old Jira projects and Confluence spaces in a cloud migration?

Teams moving from Data Center or Server to cloud often migrate only the projects and spaces they still use, and archive or leave behind the rest. The left-behind material is frequently the longest and most useful engineering and decision history the company has. For an Atlassian partner or IT consultant, the migration plan is the moment to ask what happens to it.

This page does not restate Atlassian's migration rules or end-of-support dates, which change; use Atlassian's own documentation for those. It covers what the records are, why AI buyers may value them, and how an IT consultant flags them without ever touching them.

What history do Jira and Confluence hold?

Depth varies by company. A team that has used the same instance for eight years across several products holds a far richer record than one that started fresh two years ago. Archived projects from retired products count, which is why the "old stuff we are not migrating" list matters.

What export and retention realities should a consultant ask about?

Ask generic questions; do not assume vendor limits. Check Atlassian's current documentation for any specific limit.

• Which projects and spaces are in scope for the migration, and which are explicitly out?
• What is the plan for the out-of-scope ones: keep the old server running read-only, export to storage, or delete?
• Who is the instance administrator, and can they run a full export including attachments and history?
• Is a retention policy in place that deletes old issues or page versions automatically?
• When is the old license due to lapse, and does anyone have a date for shutting down the hosting?
• Are third-party apps holding data (test management, time tracking, roadmaps) that will not migrate?

The answers tell you whether the history will survive. The pattern to watch for is "we will clean up after cutover", which often means the old instance is switched off the week the contract ends.

How do you spot a company that uses Jira and Confluence well?

• Several years of issue history across more than one team, not a single project
• Workflows with real statuses and resolutions, not a single catch-all board
• Confluence spaces that contain decisions, runbooks and retrospectives, not just meeting notes
• Links between issues, code review and release records
• A service desk or internal request queue with approvals
• An administrator who knows where the old instance lives and when it is retired
• The wider company baseline: 50+ full-time employees at peak (contractors excluded), an authorized sponsor and rights to license the records

Jira and Confluence rarely stand alone. Strong companies keep records across email, chat, CRM, finance, support and engineering, often 10-15+ systems, and the Atlassian history is one strand. The article on what gets left behind in a Salesforce to HubSpot move and the one on old mail in a Google Workspace to Microsoft 365 move cover the neighbouring systems.

When in the migration project should you raise it?

The last row is the one that matters most. Deletion approval is a business decision, not a technical clean-up. Pair this with the broader guidance on cutting cloud storage costs without deleting valuable data and CRM clean-up before migration.

What to say to the client

For a longer treatment of engineering-focused engagements, see spotting data referral opportunities in Jira projects. The introduction email builder can help draft the message.

Pitfalls

• Migrating only active projects and treating the rest as disposable.
• Letting an automated retention rule purge old issues before anyone asks.
• Assuming Confluence attachments and page history are included in a standard export without checking.
• Forgetting client-specific projects: if the instance holds work done for clients, the rights may belong to them. That is a red flag unless clients consent.
• Touching content yourself. Consultants make introductions and give basic fit information only; they never export, upload or describe confidential records.

For companies on managed IT, the referral opportunities for managed service providers page applies the same logic across a client base.

How rewards work for IT consultants

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company. The reward is paid only after the buyer pays and SourceX receives its fee; an introduction, meeting or signed agreement alone does not trigger payment, and no reward is guaranteed. Read the program terms before you register, and check your own contracts with clients for any rule on referral fees or disclosure.

Next step

Add one line to your migration checklist: "history not migrating, owner, retention decision." If a client has years of engineering history heading for the archive, register as a partner and introduce the sponsor, or check fit first on the who qualifies page.