Confluence Data Center to Cloud: a migration checklist for 2026–2029

Checked against Atlassian's documentation on 3 November 2026. Written by the maker of Spacewright, a Confluence Cloud app. Spacewright is not a migration tool; it is named only at the three steps where it helps once you are on Cloud.

The dates that set the pace

Server products are already past their end of support. Bitbucket and Bamboo Data Center follow different rules; this page is about Confluence.

1. Take stock (before anything moves)

• Spaces: list every space with its owner, size and last update. Decide which to migrate, which to archive first, and which to leave behind.
• Apps: run the app assessment in the Confluence Cloud Migration Assistant. Mark each app as needed in Cloud, not needed, or replaced by an alternative. App data moves only where the vendor offers an automated migration path.
• Macros: user macros have to be rebuilt as apps in Cloud, and some deprecated macros are removed. Find the pages that use them.
• Built-in features your teams rely on. Some Data Center features have no Cloud equivalent. Ask how teams do these jobs today:
  • Copying a whole space: Data Center has Space tools → Overview → Copy Space. Confluence Cloud has no whole-space copy (CONFCLOUD-3191). In Cloud you duplicate the page tree into a new space instead (how; what changes for Copy Space users).
  • Starting new spaces from a standard layout (a space blueprint, a "template" space someone copies, or an app). Blueprints do not migrate (what to do instead).
• Global settings and permissions: these are set up by hand in Cloud. Write down what you have.
• People: users and groups, single sign-on, and who will be space admins in Cloud.

2. Do a test migration

• Migrate a handful of typical spaces, including the largest and the most macro-heavy, to a test Cloud site first.
• Check pages, attachments, macros, page restrictions and links. Jira macros from Plans need Atlassian's Jira Macro Repair after migration.
• Time it. The test tells you how long the real batches will take.

3. Move

• Announce a content freeze for the spaces in each batch.
• Migrate in batches with the migration assistant, and keep a list of what moved and when.
• Leave the Data Center site read-only for a while, so people can compare.

4. After the move

1. Fix links. Run Atlassian's link fixing, spot-check a sample of links and run it again if some still point to the old site.
2. Rebuild what does not migrate: global settings and permissions, user macros (as apps), and anything your app assessment flagged.
3. Check templates. Atlassian says global page templates and custom system templates migrate. Open a few spaces and confirm their own page templates came across. Blueprints are not migrated, and "Create from template" buttons that point at built-in blueprints can break (details and the open bug). Recreate what is missing.
4. Decide how teams will create standard spaces in Cloud (client, project, service knowledge base). Write the routine down; here is one.

   Where Spacewright helps (1 and 2): turn the agreed structure into a template space with placeholders such as {{client}}. New spaces then come from one form, with values filled in and links switched to the new space. For teams that used Data Center's Copy Space, Spacewright copies a whole space on the same Cloud site, with a dry run first and a report at the end. It does not copy comments, page history, whiteboards or databases, nor the space logo, description or sidebar. Data Center's Copy Space could include comments and space settings, so tell teams what changes. Other Marketplace apps also copy spaces; compare them. Examples: templates for consultancies.

5. Clean up structure on a copy first. Migration is a good moment to merge, split or rename. Try big changes on a copy, not on the space people are using.

   Where Spacewright helps (3): it copies the migrated space to a sandbox space on the same site. Links in the copy point to the copy, and the source is only read, so you can rehearse a restructure safely. Then repeat the changes on the real space. The copy has no comments or page history, so it should not replace the original.

6. Backups: XML space and site export lose support in Confluence Cloud on 1 December 2026; CSV export stays supported (details).
7. Close out: train space admins, archive spaces nobody needs, and set a date to switch off the old site.

What Spacewright does not do in a migration

• It does not move content from Data Center or Server. Use Atlassian's migration assistant.
• It does not copy between two Cloud sites. Use Atlassian Administration's tools for transferring data between sites.
• It does not fix links in migrated spaces. Use Atlassian's link fixing.
• It is not a backup tool. Use CSV export.

Full list of what it copies: Copying a space and Limits and known gaps.

Sources

• Atlassian: Data Center end of life
• Atlassian: What migrates with the Confluence Cloud Migration Assistant
• Atlassian: Assess Marketplace apps with the Confluence Cloud Migration Assistant
• Atlassian: Fix links after the migration and Post-migration tasks
• Atlassian (Data Center 10.0 docs): Copy a Space
• Atlassian: Transfer Confluence data (between Cloud sites)
• Feature request: CONFCLOUD-3191 (copy a space in Confluence Cloud)