How to Archive Jira DC Issues Before a Cloud Migration

29 Jul 2026 · By Brian Parks, CEO — Synapse Software
Former Senior Software Engineer at Cherwell Software (2017–2020)

Your Cloud migration plan has a number on it: how many projects move. It has no number for how many years of closed issues get left behind. That number is usually large, and it is usually what makes the migration slow.

I spent years building on a service-management platform before I built an archive company, so I have a low tolerance for migration plans that quietly strand history. Jira Data Center is the next big version of that problem, and the clock is now public.

The Jira DC clock is real, and it is not December 2026

Cherwell forced this conversation on thousands of teams with a hard deadline. Jira Data Center is doing the same on a longer fuse. Atlassian’s dates are set: Jira Software DC and Jira Service Management DC reach end of life on March 28, 2029, when environments go read-only and unsupported, with access past that date only by exception. New-customer sales ended in March 2026; existing-customer sales end in March 2028.

Three years feels like room. It is not room to ignore the historical record, only room to handle it deliberately instead of in a panic, which is the one advantage you have over the Cherwell teams scrambling before their December 2026 deadline.

Why migrations leave history behind on purpose

A Jira DC to Cloud migration is sold on the new platform: better collaboration, native AI, no infrastructure to run. The tooling is built to move what makes the new instance useful on day one: active projects, current workflows, recent issues.

What it is not built to do cheaply is carry a decade of closed issues with full fidelity. The longer the history, the more custom fields, issue links, transitions, comments, and attachments come with it, and the more the migration slows and the bill climbs. So teams make a rational call under pressure: migrate a recent window, leave the rest in Data Center.

That works right up until the license lapses. Then the history you left behind is stranded in a read-only, unsupported environment you are still paying for, or it is gone.

Archive first, then migrate light

Invert the default. Instead of migrating everything and hoping the history survives, archive the full historical dataset into a read-only system you control, then migrate only what Cloud actually needs.

This buys three things. The cutover gets faster and cheaper, because you move a recent window instead of a decade. The record stays whole and in context, not thinned to fit a migration budget. And you stop depending on a Data Center license to read your own past, before “just keep DC running for read access” hardens into an expensive habit.

That habit is not free. Keeping a sunset platform alive just to read old records is a bill that recurs every year for nothing new, and migrating a decade of history instead is a professional-services project of its own, which is exactly why most migration SOWs leave historical data out. An archive you own avoids both bills.

A 30,000-person manufacturer moving to ServiceNow treated this as the order of operations, not an afterthought. Its concern was not the new platform; it was preserving years of change requests and security incident records for audit. So it validated an archive in an independent trial, confirmed the records came across intact, stood it up alongside the new system in about a month, and migrated forward from there.

What a faithful Jira archive has to keep

Archiving Jira issues is not the same as exporting them. An issue stripped of its links, custom fields, workflow history, comment threading, and attachments is not the issue. It is a summary of it. We break down why that gap matters for audits and AI in Jira CSV export vs. a purpose-built archive.

A faithful archive keeps the issue whole: the fields as they were, the links to related issues, the full comment history, the attachments, and search that works the way the live system did. For Jira Service Management, that includes the request history and audit trail compliance teams actually get asked for.

Where Cortex fits

Cortex Archive supports Jira Data Center archives on its current 3.1.0 release. It reads your Jira DC database directly and rebuilds a familiar, read-only interface to it inside your own network, so the record stays intact, searchable, and on your infrastructure, with nothing handed to a third party. You migrate the active estate to Atlassian Cloud and leave the long tail in an archive you own. Cleaner cutover. Complete record. No DC license required to read your own past.

Beyond keeping the record, that changes three numbers on the business case.

Efficiency. One archive holds the history from every platform you retire, Jira today and whatever comes next, in one familiar interface instead of a shelf of dead systems and export folders. The 3.1.0 release adds REST API access and unified search across archive types, so the history is not just stored, it is wired into your people and your own tools. AI-powered search is rolling out on a bring-your-own-model architecture, so the records feed the AI you choose rather than sitting in cold storage.

Time. The migration itself shrinks, because you move a recent window instead of a decade, which makes the cutover faster to run and faster to test. And every audit after gets shorter: when someone asks for a change from three years ago, your team opens it in context and searches the way they searched the live system, instead of writing SQL or combing a SharePoint folder to rebuild a record under deadline. A read-only archive that stands up in weeks, not a project that runs for months.

Risk. This is a compliance exposure before it is a technical one. Your data retention policy, and the regulations behind it, SOX, HIPAA, GLBA, and your industry’s rules, still apply to the Jira history whether or not the platform survives. An archive you own keeps you compliant with those obligations, so when the auditor arrives you have the record they ask for, in full context, and produce it on the spot instead of explaining why it is gone. It is read-only by design, on a database user with no write permissions, so the record cannot be altered even by accident, which is the integrity an audit looks for. And you stop depending on an end-of-life platform, one that loses security fixes after 2029, to hold evidence you are legally required to keep.

Migrate to Cloud. The platform is good and the direction is set. Just decide, on purpose, what happens to the years you are not bringing with you, before Data Center goes read-only on you.

Frequently Asked Questions

When does Jira Data Center reach end of life?

Atlassian announced Data Center end of life in September 2025. New license sales to new customers ended March 30, 2026. Sales, expansions, and Marketplace app sales for existing customers end March 30, 2028. Full end of life arrives March 28, 2029, after which Data Center environments become read-only and unsupported.

Does migrating Jira DC to Cloud move all my historical issues?

Not by default. Migrations typically prioritize active projects, current workflows, and recent issues. Carrying a decade of closed issues with full fidelity is slow and expensive, so long-tail history is often left in Data Center. That history then depends on a Data Center license you are trying to retire.

Why archive Jira issues before migrating instead of after?

Because before the migration you still have a fully supported source system to archive from and validate against. Archiving first lets you migrate a smaller, recent dataset to Cloud, which makes the cutover faster and cheaper, and it removes the temptation to keep paying for Data Center just to read old issues.

What does a Jira CSV export lose?

A CSV export strips issue links, custom field context, workflow transition history, comment threading, and attachments. You keep a flattened table of values, not the issue in context. For audit evidence and for training AI on historical patterns, that loss is the whole problem.

Can I keep Jira Data Center running just to read old issues?

You can, until full EOL in March 2029 makes it read-only and unsupported. At that point you can view data but cannot act on it, you stop receiving security fixes, and continued use is available only by exception. Even before then it is an annual license cost for no forward value. A read-only archive you own preserves the same records without the recurring bill or the dependency on an end-of-life platform.

What happens to my Jira data at Data Center end of life?

After March 28, 2029, impacted Data Center licenses and their Marketplace apps expire and the environment becomes read-only. You can still view historical data, but you cannot create, edit, or collaborate, and support and security updates end beyond Atlassian’s covered window. Continued use past that date is available only as an extended-maintenance exception. Archiving the history into a system you control removes that dependency entirely.

Does Cortex Archive support Jira Data Center archives?

Yes. Cortex Archive supports Jira Data Center archives on its current 3.1.0 release, using the same on-premise, read-only architecture it uses for other platforms. It stands up a copy of your Jira DC data inside your own network, preserving fields, links, comments, and attachments, so the historical record stays intact and searchable after you migrate the active estate to Cloud.

Before your Jira Data Center to Cloud cutover, Cortex Archive preserves your full historical issue record on your own infrastructure, read-only and searchable, so you migrate light and keep everything.