Confluence Cloud Migration Assistant (CCMA) Failures: Recovery Guide

Your Confluence Cloud Migration Assistant run failed. Maybe the progress bar stalled and never recovered. Maybe you woke up to a java.lang.OutOfMemoryError in atlassian-confluence.log. Maybe spaces show as "migrated" but half the content is missing.

This is fixable — but only if you fix the root cause before rerunning. Blindly retrying the same plan is how partial failures become messy identity and permissions problems. Most failed CCMA migrations fall into a small set of patterns: native thread exhaustion, oversized XML exports, user/email conflicts, blocked Atlassian endpoints, unsupported H2, or app-data gaps. (support.atlassian.com)

This guide covers the seven most common CCMA failure modes, the exact fixes for each, what gets silently dropped that you won't notice for weeks, and when the right move is to stop fighting the tool and bring in help. For the full end-to-end migration process, see our Confluence Server to Cloud Migration: The Technical Guide. This post assumes you're already mid-migration and something has gone wrong.

Before you touch anything else: update CCMA. Atlassian has ended support for versions 3.3.6 and lower, and older versions have known bugs that cause enable/disable loops and activation failures. The current release line is 3.13.x. If you're debugging on an older build, you may be spending hours on a bug that's already been patched. (support.atlassian.com)

If the latest version breaks your specific Confluence version, you can install a specific older version by downloading the JAR from the Atlassian Marketplace version history. Use the dark feature flag migration-assistant.disable.app-outdated-check to bypass the version check if needed.

1. OutOfMemoryError: Thread Contention During Attachment Migration

This is the single most common CCMA failure at scale. You'll see it in atlassian-confluence.log or Tomcat's catalina.out:

java.lang.OutOfMemoryError: unable to create native thread:
possibly out of memory or process/resource limits reached

What's actually happening: Despite the name, this is rarely a RAM issue. CCMA spawns threads to upload attachments in parallel. When migrating spaces with large attachment volumes, thread creation exhausts OS-level limits — not JVM heap. Your heap can be 16 GB and only 16% utilized, and you'll still hit this error. The constraint is the operating system's cap on threads and open file descriptors, not Java memory. (support.atlassian.com)

The fix: Increase nofile and nproc limits for the Confluence system user. Atlassian recommends a maximum processes value of at least 4096. On Linux, edit /etc/security/limits.conf: (support.atlassian.com)

confluence  soft  nofile  4096
confluence  hard  nofile  8192
confluence  soft  nproc   4096
confluence  hard  nproc   8192

Replace confluence with the actual system user running your Confluence process.

After the restart, reduce the number of spaces per migration plan. A confirmed bug (MIG-1702) shows that plans with 30+ spaces reliably trigger this OOM even with nproc set to 32k. The workaround: migrate in batches of 10 spaces.

If attachments are what push you over the edge, stop doing them in the final cutover window. Atlassian supports attachments-only pre-migrations — you can move attachments weeks or months early, and later migration runs recognize already-migrated files and skip them. This shortens the risky final pass significantly. (support.atlassian.com)

2. 200 MB XML Export Limit Exceeded

CCMA uses XML-based space exports internally. If a single space's uncompressed XML exceeds 200 MB, the export fails. This limit is about the XML data, not the attachment payload — deleting PDFs won't solve it if the problem is page versions or inline content. Large spaces with heavy inline images, thousands of page versions, or deeply nested page trees hit this wall fast. (support.atlassian.com)

How to fix it:

• Split the space. Move page trees into sub-spaces before migration. This is manual and time-consuming, but it's the only CCMA-native fix.
• Purge page versions. Old page versions inflate XML size significantly. If you can tolerate losing history, delete old versions before export.
• Pre-migrate attachments separately. Attachments are the biggest contributor to space size. CCMA supports migrating attachments in a dedicated plan before the space migration. This alone can bring many spaces under the 200 MB threshold.

If splitting and purging aren't viable — say you have a compliance requirement to preserve all versions — CCMA's XML export path cannot handle it. You need an API-based migration that streams content directly rather than serializing to XML. Atlassian's public migration API is the official programmatic option. Our Confluence import guide covers the API alternatives in detail.

3. Throughput Cap Timeouts (400k Pages/Day)

Atlassian's documented median throughput for CCMA is 400,000 pages per 24 hours. Treat that as a planning ceiling, not a promise. A 1-million-page instance takes roughly 2.5 days of continuous migration — assuming zero errors. (confluence.atlassian.com)

In practice, throughput degrades further when:

• Multiple admins monitor the same plan. A confirmed bug (MIG-2231) shows that each admin viewing the migration plan dashboard polls the database roughly every 5 seconds, diverting resources from the actual migration and slowing throughput by up to 10x. Limit monitoring to one admin session during active runs.
• Scheduled background jobs compete for resources. Confluence's built-in jobs (search indexing, analytics, cache flushes) run during migration and consume CPU, memory, and database connections. Stop all non-essential scheduled jobs before starting a migration.
• Network latency or egress scanning. If your server routes traffic through DLP or egress scanners, upload bandwidth drops. Run a speed test from the server before production migration.

Phasing strategy: Pre-migrate users, groups, and attachments in separate plans first. Migrate inactive spaces (not edited in 24+ months) weeks before the cutover. Save only actively edited spaces for the production migration window. This approach can shrink actual downtime from days to hours.

4. Marketplace App Data Missing Post-Migration

CCMA does not migrate Marketplace app data — including data from Atlassian's own apps like Team Calendars. The apps themselves may appear in Cloud, but the data stored by those apps does not come along. App data migration depends entirely on vendor support. If an app is only at Stage 1 or the app migration fails, you need to contact the vendor directly. (support.atlassian.com)

Specifically affected:

• Team Calendars: Internal subscriptions migrate, but Jira-linked calendar events do not. The connection between calendars and Jira projects breaks during migration.
• Gliffy, draw.io, Lucidchart: Diagram data is vendor-specific. Contact each vendor before migration for their recommended path.
• ScriptRunner, Comala Workflows: Automation configurations and workflow states require manual recreation in Cloud-equivalent apps.

What to do:

1. Inventory every Marketplace app in your instance (Administration > Manage apps).
2. Contact each vendor before migration. Most vendors publish Cloud migration guides. Some provide migration utilities; others require Atlassian support coordination.
3. For apps without a Cloud equivalent, export the data before migration starts. Some app data can only be recovered from the Server database directly.

If app-held data is business-critical, do not finish cutover until you know which recovery path you're on for each app.

5. User Mismatch and Duplicate Emails Between Jira and Confluence

In Atlassian Cloud, users are keyed by unique email address, not by legacy Confluence username. If you're migrating Confluence and Jira to the same Cloud site, user identity conflicts are near-certain. CCMA uses email addresses to map users — if the email already exists in Cloud, CCMA links content to that existing account. If UserA has usera@example.com in Confluence but user.a@example.com in Jira, the migration assistant treats these as different users. Invalid emails or multiple users sharing the same email will block migration entirely. (support.atlassian.com)

The result: Duplicate accounts, broken content ownership, and permission escalation risks.

Before migration:

• Audit email addresses across both Confluence and Jira databases. Every shared user must have the same email in both systems.
• Settle identity first, then move spaces. Atlassian recommends migrating users in advance, especially for large environments. Teams with over 1,000 users should strongly consider partner help. (support.atlassian.com)
• Choose one email remediation strategy and stick with it across the whole migration. Changing strategies between runs creates inconsistency. (support.atlassian.com)
• Watch for blocklisted admin groups: site-admins, system-administrators, atlassian-addons, atlassian-addons-admin. These groups are not migrated. Users in them still migrate, but you must manually re-add them to admin groups in Cloud.
• Watch group linking carefully: same-name Cloud group matches and re-migrated groups can create permission escalation if memberships changed between phases.

6. Proxy or Firewall Blocking Atlassian Domains

CCMA needs outbound connectivity to multiple Atlassian domains. If any are blocked by your firewall or reverse proxy, the migration either fails outright or stalls with a "We can't communicate with your server" error.

Required domains (at minimum):

• *.atlassian.com
• *.atlassian.net
• *.atl-paas.net
• api-private.atlassian.com
• api.media.atlassian.com (for attachments)
• migration.atlassian.com
• migration-service.services.atlassian.com
• marketplace.atlassian.com (CCMA checks for updates before every run)
• Your destination Cloud site URL
• Amazon S3 upload endpoints

Required IP ranges: The full list is at Atlassian cloud IP ranges and domains. Atlassian uses AWS infrastructure, so customers with strict egress controls may also need to allowlist AMAZON and CLOUDFRONT IP ranges.

If the allowlist is correct and you still see TLS failures, go one layer deeper. Atlassian has separate KB articles for CCMA communication errors caused by an outdated Java truststore and for certificate mismatches on api-private.atlassian.com when SNI is disabled. These cases look like migration problems in the UI but are really Java/network plumbing issues on the source node. (support.atlassian.com)

Before production migration, confirm that no DLP, egress scanners, or SSL inspection appliances are interfering. These silently throttle upload bandwidth or cause intermittent disconnects that look like CCMA bugs.

7. H2 Database Incompatibility

CCMA does not support the H2 embedded database. Atlassian deprecated H2 in Confluence 8.0, but many older Server instances — especially small teams who never changed the default — are still running it. If you attempt to run CCMA on H2, the assistant either fails to activate or throws GenericJDBCException during pre-flight checks. (support.atlassian.com)

The only fix: Migrate your Confluence database from H2 to PostgreSQL, MySQL, or another supported database before attempting Cloud migration. Budget at least a day for this; H2-to-PostgreSQL migration on a large instance requires careful testing of character encoding and stored procedures.

What CCMA Silently Drops

Not all failures generate error codes. The most dangerous CCMA failures report 100% success while leaving critical data behind. These data types do not migrate, and CCMA does not warn you about most of them: (support.atlassian.com)

The dangerous ones are personal drafts and audit logs. Users won't notice missing drafts until they go looking — often weeks after cutover. Audit logs are irreplaceable once the Server instance is decommissioned.

Use this as your silent-loss checklist before shutting down the source:

• Personal drafts: Ask users to publish or copy anything important before the freeze.
• Custom emojis: Inventory and recreate them in Cloud.
• Avatars: Warn users they'll need to re-upload.
• Audit history: Export or retain it outside Confluence for compliance or investigations.
• App data: Confirm every app's migration path individually — not by assumption.

The Legacy Editor Problem (Already Live)

Every page migrated by CCMA lands in Confluence Cloud in legacy editor format. Atlassian has fully deprecated the legacy editor in phases: (support.atlassian.com)

• Phase 1 (January 21, 2026): New pages cannot be created in the legacy editor.
• Phase 2 (January–February 2026): Auto-conversion of legacy pages begins. Opening a legacy page converts it to the Cloud editor.
• Phase 3 (April 1, 2026): Legacy editor is fully deprecated. All content is viewed and edited in the Cloud editor. No revert option.

What this means for migrated pages: CCMA-migrated content is now forced through Atlassian's auto-conversion path. For simple pages, this is fine. For pages with complex layouts, nested bodied macros, custom CSS, or legacy-only macros (like the Gallery macro), auto-conversion breaks formatting. Atlassian wraps unconvertible content in a "Legacy Content Macro" that preserves it as read-only — but you lose the ability to edit those sections natively. Macros supported only in the legacy editor will not work in the Cloud editor. (support.atlassian.com)

Action items:

1. After migration, use the space admin tool to identify legacy pages in each space.
2. Test conversion on complex pages individually before allowing bulk auto-conversion.
3. If your migration includes heavy macro usage, nested content patterns, or pages used as templates, you need post-migration rendering QA — not just a checkbox that says "migration finished."

If exact formatting is non-negotiable and the Cloud editor's conversion path is a bigger risk than the original move, it's worth revisiting the target platform. Our Confluence Alternatives (2026) comparison is a better next read than another blind rerun.

Recovery Strategy: Rollback vs. Delta Sync vs. Re-Run

When CCMA partially completes, you have three options. The critical detail: CCMA does not overwrite existing Cloud data. If you re-run into the same destination without cleaning up first, you'll get space key conflicts and compound the problem. (support.atlassian.com)

Option 1: Wipe and Re-Run

When to use: The migration failed early (less than 20% of spaces migrated), your user/group strategy needs to change, or permissions are already wrong.

Delete the partially migrated content from Cloud (or use a fresh test site), fix the root cause (OS limits, firewall, space size), and re-run CCMA from scratch. You must wipe first — CCMA will not overwrite existing data, so a rerun without cleanup creates conflicts. (support.atlassian.com)

Option 2: Continue with Remaining Spaces

When to use: Most spaces migrated successfully, and only a few failed. CCMA tracks migration status per space — you can create a new plan that includes only the failed spaces.

Check the CCMA dashboard for the specific failure reason per space. Fix the root cause (usually the OOM error or attachment timeout), then re-run only the failed spaces in a new plan.

Option 3: Delta Sync via the Migration API

When to use: The migration completed, but content was added to Server during the migration window, or you need to sync specific spaces without re-migrating everything.

Atlassian's public migration APIs allow programmatic migration outside the CCMA UI. These APIs let you create jobs, run pre-checks, and track task status — they become the control plane for a custom delta pass when another full UI rerun is too risky. This requires engineering effort. It is not a point-and-click operation. Our Confluence import guide covers the API side in detail.

For broader patterns on recovering from stalled migrations across platforms, our Engineer's Rescue Guide for Failed Migrations covers the operational decision framework.

When to Bring in an Engineer-Led Migration

CCMA is a solid tool for straightforward migrations — a few hundred spaces, clean data, no app dependencies, flexible downtime. But it has hard architectural limits that no amount of tuning can overcome.

Stop treating this like a normal admin cleanup task when:

• Scale exceeds 1,000 users or 100 GB of content. Phasing strategies become complex enough that one misconfiguration wastes days.
• Regulated industry requirements demand audit trail preservation, zero data loss, or compliance documentation for the migration itself.
• Weekend or holiday cutover with no margin for error. CCMA doesn't support pause-and-resume; a failed run means starting over.
• Marketplace app data must survive. If Team Calendars, Comala, or other app data is business-critical, the migration needs vendor coordination and custom extraction scripts.
• Post-April 2026 migration where you need pages in Cloud editor format from day one. CCMA always lands content in legacy format, which now immediately hits auto-conversion.

At ClonePartner, we've run 1,200+ data migrations and built direct API integrations that bypass CCMA's XML export limits and throughput caps. Our approach uses delta syncs so your team keeps working during migration — no weekend cutovers, no read-only lockouts. We handle the macro mapping, app data extraction, and post-migration validation that CCMA leaves on the table.

If the blocker is really an Atlassian defect, we'll say that plainly and help you escalate it — we don't pretend a script can solve everything.