This is a chapter of the leaving Jira migration guide. It covers what to verify after the migration tool reports success, and why that is a different list from the one the tool checks.

A migration is not done when the tool reports success. It is done when you have verified the things the tool does not report on.

That distinction sounds pedantic until you look at what a migration tool actually monitors. It reports on the operations it performed. It does not report on the categories of data it never attempted, and it generates no warning for them, because from the tool’s point of view nothing went wrong. Your green checkmark is accurate and incomplete at the same time.

This chapter gives you the validation pass. Most of it is drawn from a field guide to Confluence Cloud Migration Assistant failures published by Roopendra Talekar on 8 May 2026, which is the most detailed public account of what goes wrong and what goes missing. It is a partner’s practitioner guide rather than vendor documentation, so it is attributed to him throughout, and its throughput number is his planning estimate rather than a specification.

The silent losses

Talekar lists what does not arrive and generates no warning that it did not:

Audit logs
Personal drafts
Custom emojis
User avatars
Blocklisted admin group memberships

Four of those five are cosmetic or recoverable. The first is not, and it is the one to check before anything else on this page. The migration gotchas guide covers the same territory from the other end, under what gets lost even when a migration reports success.

An organisation under a retention obligation or an evidentiary hold does not merely want its audit log. It is required to be able to produce it, on request, to somebody who will not accept “the migration tool did not carry it across” as an answer. And because the loss is silent, the ordinary way this is discovered is months later, during an audit or an investigation, after the source system has been decommissioned. At that point the record does not exist anywhere.

If you take one action from this chapter: before you decommission anything, confirm that the audit history you are obliged to keep is available in the destination, or has been exported and stored somewhere that is not either system. Do that while the source is still running, because that is the only window in which the fix is easy.

App data does not come with the tool, including the vendor’s own

The app-parity problem is normally discussed as a third-party Marketplace question. Talekar’s guide states it more broadly:

CCMA does not migrate Marketplace app data—including data from Atlassian’s own apps like Team Calendars.

Atlassian’s own apps are on the same footing as everyone else’s. If your teams keep anything of record inside an app, and Team Calendars is a good example precisely because nobody thinks of it as app data, that content is not part of what the migration moved. Each app has its own migration path supplied by its own vendor, and each of those is a separate piece of work with a separate owner and a separate verification step.

The validation checklist

Run this in the destination, against the source, with the source still running.

Audit log availability. Can you produce the audit history for a date twelve months ago, in the destination, today? If not, where does it live and who has it? Nothing else on this list matters as much.
Marketplace app data, including the platform vendor’s own apps. One row per app, per the app inventory chapter. Confirm the data arrived, not that the app installed.
Identity mapping, resolved rather than merged. Duplicate or mismatched user emails across Jira and Confluence are one of Talekar’s named failure modes. The bad outcome is not a failure, it is two people quietly becoming one account. Spot-check accounts that share a surname, accounts belonging to contractors, and anyone who has changed name or email during the life of the instance.
Attachments, by count and by total size. Compare against the source. Attachment migration is where Talekar’s thread-exhaustion failure appears, and a partial attachment set is easy to miss because the pages themselves render.
Permissions and restrictions. Pick the ten most sensitive spaces or projects and confirm that the people who could not see them still cannot.
Drafts, avatars and emojis. Cosmetic, but confirm rather than assume, and tell people rather than letting them discover it.
Search. Content that migrated but is not indexed is content your users cannot find, which they will experience as content that did not migrate.
Export back out. Confirm you can get the data out of the destination. This is the step that is almost never run, and it is the one that tells you whether you have a migration or a one-way trip.

Sizing: two ceilings and one piece of arithmetic

Validation is only possible if the migration finished, and two published constraints determine whether your plan is realistic.

A 200 MB uncompressed XML ceiling per space. Above that, Talekar reports, a single space will not export. Large, old, attachment-heavy spaces are the ones to check, and the remedy is to split the space before the migration rather than during it.

About 400,000 pages per 24 hours. This is Talekar’s planning estimate, not a specification, and he notes it degrades under concurrent admin monitoring, which is to say that watching the migration makes it slower. Divide your page count by that figure and you have the floor of your migration window, not the expectation.

The same arithmetic applies on the Jira side, from the other direction. Atlassian’s platform changelog entry of 28 August 2026 raised the bulk fetch endpoint to a maximum of 1,000 issues in a single request, up from 100. The conditions are where the sizing lives: fields must be named explicitly, no more than 100 of them, and only single-value fields, which excludes comment, worklog and attachment. Atlassian’s own guidance for the rest is direct:

If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work.

Read as a release note this is good news, and it should be described as such: a bulk API got ten times faster. Read as a sizing input it says something more useful. Everything the fast path will hand you a thousand at a time is the summary layer. Everything it will not is the record: who said what, who logged what time, what was attached, and how the item changed. So size your extraction window on comments, work logs, attachments and change history, because those are excluded from every bulk optimisation on offer. The estimate that turns a two-day export into a two-week export is the one worth having before you book the weekend.

If you have not put numbers on the estate yet, the Atlassian instance sizing tool produces a migration complexity estimate alongside a cost comparison, in the browser, from figures you read off your own admin console.

Failure signatures worth recognising

Talekar documents seven failure modes with their error signatures. Three are worth knowing in advance because the obvious remedy is the wrong one, or because the fix belongs to a team that is not in the room.

“unable to create native thread: possibly out of memory or process/resource limits reached” during attachment migration. This is OS-level thread exhaustion, not heap saturation, so adding heap does not fix it. It is a process and resource limit question for whoever owns the host.
Connectivity failures where the network path to *.atlassian.com, api-private.atlassian.com and the relevant S3 endpoints is not open. This surfaces as an intermittent migration problem and is a firewall and proxy change, which usually means a different team and a lead time.
“CCMA does not support H2”, a flat refusal. Estates still running the evaluation database discover this at the worst possible moment.

The fair framing on all of these: they are known, documented and mostly recoverable, with published workarounds. The argument of this chapter is not that the tooling is broken. It is that a migration needs a validation pass, and that the pass has to cover the things no tool reports on.

Do not decommission until the checklist is clear

A cloud migration is a one-way door, and the only thing holding it open is the instance you have not turned off yet.

That reframes a cost most organisations resent. Running both systems in parallel looks like waste on a budget line, and it is usually the first thing cut when the migration runs long. It is not waste. It is a deliberately purchased option, and its value is the entire archive if any item on the checklist above comes back wrong. Price it that way when somebody asks why the old licence is still on the invoice.

How long you can hold that door open is a licensing question rather than a technical one, and it is worth checking against the Data Center deadline dates before you plan the overlap. The renew-or-expand date and the end-of-life date are different, and which one binds you depends on your current licence position.

The proportions are worth stating plainly, because they are what makes the decision easy. The cost of verifying is a few days of somebody’s attention. The cost of not verifying is discovered later, by someone else, and is measured in years of records.

Sources: Roopendra Talekar, Confluence Cloud Migration Assistant failure and recovery guide, ClonePartner, 8 May 2026; the failure modes and silent-loss list are his, and the throughput figure is his planning estimate rather than a specification. Atlassian, Jira Cloud platform changelog, 28 August 2026. Verified 1 September 2026.