DC to Cloud and Cloud to Cloud, plus the audit that proves it worked.
A migration that reports success is not the same as a migration that worked. Filters arrive pointing at fields that no longer exist. Automation rules arrive enabled and scoped to the wrong project, and Jira quietly rewrites the trigger so a source-to-target diff passes. Attachment downloads redirect somewhere your script does not follow. None of it shows up in the migration report.
Two series run through this hub. Atlassian Migrations is the planning half, in order, and it spends most of its time on the work nobody is paid to do before the cutover. Auditing a Migration is the other half — what to run afterwards to find the damage while you still have the source system to compare against.
The end-to-end path of a Data-Center-to-Cloud move, in the order the problems actually arrive.
What to re-count on the far side, and the four places a migration reports success while something is quietly broken.
Two new skills in LeanZero's open-source agent skills pack. automation-engineer drives the Jira automation rules API under /automation/public/ to read, create and migrate rules between Cloud sites. atlassian-cloud-to-cloud-migration-skill copies Jira projects, JSM desks and Confluence spaces into a live site over REST. How to install them, what each one has proven, and what it hasn't.
JCMA stops with "We couldn't export Custom Field Config Scheme" and a java.lang.NullPointerException, and the same message has three unrelated causes, each documented in a different Atlassian source. Here is how to tell them apart from the log line, the fix for each, three problems in the knowledge base's own SQL, and what the Cloud-to-Cloud side looks like.
An Atlassian data security policy has seven controls, and only one of them works without Atlassian Guard: blocking all Marketplace and custom apps from chosen spaces. This post walks through what each control blocks, what the app access rule really takes away from an app, what the admin API says when you try a Guard control without Guard, and what happens to policies and classification levels on a Data Center to Cloud or Cloud to Cloud migration.
JCMA stops a project export with "We couldn't export Issue Security Level Permission 10001. Reason: java.lang.NullPointerException. [JCMA 000]" when an issue still points at a security level that no longer exists. This tutorial finds the orphaned level and the issues that reference it, fixes them in the Jira Data Center database, checks the custom-field grants JCMA silently drops, and proves on Cloud that the right people can see the right issues. The Cloud-to-Cloud route through Copy product data is covered too.
When you migrate Jira users and groups, a group whose name already exists on the Cloud site is linked to it by name. Its members inherit whatever that Cloud group can do. Here is how it works in JCMA and in Cloud-to-Cloud copy, and the audit to run first.
Confluence space permissions after migration break in two directions: people lose spaces and private pages, and other people quietly gain access when groups merge by name. This tutorial gives you a dependency-free Node script that snapshots every space permission, role, page restriction and group member, then diffs the before and after into two lists. Run on a real Cloud site, with the Data Center queries alongside.
Nested bodied macros are the one Confluence Data Center content pattern a Cloud migration cannot carry across intact, and since April 2026 there is no legacy editor left to hide them in. This walks the discovery probe on the Data Center database, the triage against what the Cloud editor actually accepts, a REST probe that shows exactly how Cloud wraps a nest it cannot render, the error string your users will paste, and the repair patterns, with the parts of the script that matter and not the whole thing.
Confluence 10.2 ships a 1 GB heap; the Cloud Migration Assistant refuses to be safe below 4 GB and, in its own code, will not start an attachment step above 80% of whatever heap you give it once its memory budget is on. This is the DC-side preparation for a large migration: a heap calculator from Atlassian's node splits, its tested heaps and your GC log, the 32 to 47 GB band to avoid, the Synchrony JVM, the thread-to-pool pairing, the assistant's documented floor and undocumented mechanics, and what Atlassian has actually tested at 102,000 users.
An Atlassian Cloud tenant has a real shape: one organization, one or more sites under it, a product provisioned per site, and a directory that decides who gets in. This is that shape, sourced from Atlassian's own admin docs, plus the part that actually matters for a migration: a Data Center move crosses every one of those boundaries fresh, while a Cloud-to-Cloud move keeps identity and uses a documented tool with its own documented gaps.
Jira 11.3 runs on Java 21 only, ships a 2 GB heap, and the Cloud Migration Assistant needs 8 to 16 GB of it just to hold issue IDs during export. This is the DC-side preparation for a large migration: a heap calculator built from Atlassian's own tables and the GC log, the 32 to 47 GB band you must not land in, the CPU-to-thread table that sets migration speed, the database pool, the timeouts, the jobs to switch off, and what Atlassian has actually tested at 80,000 users and seven million issues.
Descriptions truncated at exactly 32,767 characters. A custom field populated into a (migrated)-suffixed twin while the one on your screen stays blank. Here is how to find both, and the four-phase discipline that stops the repair becoming the next incident.
A migration report is written by the process that did the work, from the same assumptions. And the check you run instead has a worse failure: if your account cannot see a project, the audit returns zero and reads as good news.
Four ACPs, a gruelling two months, and an Atlassian Certified Expert badge at the end of it. The gamble was harvesting every dump site on the internet and refusing to believe a single answer until the documentation said so — and the free practice exams that came out of it now cover all five ACPs.
A DC to Cloud migration moves pages. It does not guarantee that what is inside them still works. Here is how to find the broken macros and lost restrictions, repair them with a backup before every write, and prove the fix on the page rather than in the API response.
A JSU condition reading priority > 5 can arrive on Cloud as priority = 5. The rule is present, enabled, and green. It now guards a different thing, and nothing anywhere reports it.
A semantic hash makes a re-run cheap. Ours also erased a mention's accountId, so two different users hashed the same and a corrected mapping would be silently skipped. Here is the pattern, the bug, and the tests that would have caught it.
A plan is built for one source-destination pair. Re-run it against another and cached IDs from tenant A land in tenant B. There is a fingerprint to stop that — and it declines to stop the plan most likely to be wrong.
Atlassian publishes what each migration tool copies. Turning that page into a scope document takes six steps and one insight most people miss: some things are copied partially, and a tool that reports those as done will cost you the migration.
DC to Cloud spends its budget resolving who everyone is, because usernames do not exist in Cloud. Cloud to Cloud gives you identity for free and a first-party copy tool — then bills you for the specific things that tool does not take.
JCMA brings your rules to Cloud disabled and without their actors. Cloud-to-cloud brings nothing at all. Measured on a live Cloud site: the Rule Management API's 400s that name no field, the app-actor discovery our own runbook got wrong, and the scope ARI the API silently rewrites behind your back.
Jira Cloud answers 303, Confluence answers 302, and an SSO-fronted Data Center answers with a login page. I measured the two Cloud cases end to end, and the failure that follows passes every audit you are likely to write.
Jira Cloud answers a JQL query about a custom field that does not exist with HTTP 200 and a count of zero. In a post-migration field audit, zero is the number that authorises deleting the field. I swept all 197 custom fields on a live site to find out which gate actually catches it.
A saved filter is a string, not a binding. I measured what cf[10042] actually resolves to on a destination site, and where Data Center to Cloud and Cloud to Cloud each fail silently.
Clean up before you migrate is the most-repeated advice in the Atlassian world, and almost nobody takes it. Not because they're lazy — because every incentive in the room, mine included, is paid to move more, not less. Follow the money.
Everyone's braced for the 2029 Data Center deadline. Almost nobody's watching the one that lands at the end of 2026 — sitting under the apps you already paid to move. Atlassian Connect is on a published end-of-support countdown, and two of its three phases have already passed.
Permissions, Assets data shape, and Assets scope — the three places where I keep watching migrations slip and budgets balloon. None of them are anyone's fault. All of them are dramatically cheaper to fix before migration than during.
After enough Data Center to Cloud migrations, you develop an instinct for when things are about to go sideways. It's never the core data — Jira issues, Confluence pages, user accounts — that breaks the project. It's the apps. Specifically, it's the moment you realize the vendor doesn't have an answer either, and your client's deadline doesn't care.
After 10+ Data Center to Cloud migrations, here's what nobody tells you: they're imperfect by necessity, not by design. Waiting for perfection is the single most expensive mistake an organization can make — and I've watched it happen in real time.
Atlassian Cloud replaces Cloudflare with a fully managed AWS-native security stack — Amazon CloudFront for CDN, AWS WAF for application-layer firewalling, and AWS Shield Advanced for DDoS protection. The stack is enterprise-grade and battle-tested, but you can't touch it. This post maps every Cloudflare capability to its Atlassian Cloud equivalent, details the gaps your security team needs to plan for, and gives you the honest technical assessment for your Data Center migration.
The real work in a cloud migration is getting to zero data loss. That starts with a thorough assessment -- knowing exactly what you have, what will not migrate automatically, and what needs hands-on validation. This is a practical guide to gathering that data using SQL queries, REST API scripts, and ScriptRunner Groovy snippets.