Planning a phased Confluence Data Center to Cloud migration? A practical, step-by-step playbook (from assessment through cutover) covering what CCMA does and doesn't solve.
Introduction
Assess your Data Center environment
Choose your approach: big bang vs. phased
Build your plan and timeline
Run the initial transfer with CCMA
Solve the parity problem during a phased rollout
Validate before each cutover
Clean up and finalize each space post-cutover
Decommission Data Center
Post-migration: operating with confidence
Most Confluence Data Center to Cloud migrations don’t happen on a single cutover date. They happen in phases, department by department, over weeks or months — because that’s the only realistic way to move an active knowledge base without freezing the business to do it.
This playbook is for whoever owns that plan: a Confluence Administrator, an IT Manager, or a Migration Lead figuring out what actually has to happen between “we’ve decided to migrate” and “Data Center is decommissioned.”
It’s tool-agnostic where it can be.
Where a specific gap needs a specific kind of tool, this says so directly, rather than pretending the gap doesn’t exist.
Before you plan anything, know what you’re actually moving.
Inventory your spaces
List every space, its owner, page count, and attachment volume.
Flag which ones are actively used versus dormant — dormant spaces are candidates for archiving instead of migrating.
Check macro and add-on compatibility
Some macros and third-party apps that work on Data Center don’t have a direct Cloud equivalent, or behave differently once migrated.
Identify these early; they’re the most common source of “why does this page look broken” tickets after a transfer.
Map your permissions structure
Space and page-level restrictions, user groups, and anonymous access settings don’t always translate one-to-one between Data Center and Cloud.
A permissions audit now saves an access-related fire drill later.
Note scale
Large, attachment-heavy spaces take longer to transfer and longer to validate.
Size isn’t a blocker, but it affects your timeline and should shape which phase a space lands in.
The output of this step should be a simple inventory: space name, owner, size, complexity flags, and a first-pass migration priority.
Big bang means everyone cuts over on one date. It’s simpler to plan and gives you one clean before/after — but it requires a full change freeze across every team that touches Confluence, which is rarely realistic once you’re past a certain org size or have globally distributed teams who can’t all freeze on the same weekend.
Phased means migrating by department, business unit, or space group, over a series of scheduled cutovers. It’s more forgiving — a bad cutover affects one team, not the whole company — but it means running two live environments simultaneously for the duration of the rollout, which is where most of the operational complexity in this playbook comes from.
In practice, most enterprise migrations end up phased, simply because a full change freeze at scale is hard to pull off cleanly. If you're a small, single-site organization with low Confluence usage, big bang may genuinely be simpler. Everyone else should plan for phased and read the rest of this playbook with that in mind.
Sequence your phases deliberately
Start with lower-risk, lower-visibility spaces to build confidence and work out process issues before you touch anything business-critical.
Assign an accountable owner per phase
Someone specific — not “the IT team” — who signs off that a phase is ready to cut over.
Set a communication cadence
Decide who needs to know before, during, and after each cutover, and how they’ll be told.
Confusion about “which environment has the current version” is the single biggest source of user frustration during a phased migration.
Define success criteria before you start each phase, not after.
What does “this phase is done” actually mean — content parity confirmed, permissions verified, no open critical bugs?
Write it down before the phase begins so there’s no ambiguity when it’s time to call it complete.
Atlassian’s Confluence Cloud Migration Assistant (CCMA) is the official tool for moving Confluence content from Data Center to Cloud, and it should be the starting point for any migration. It handles the structured content transfer — spaces, pages, and standard content types — and Atlassian maintains guidance for supported migration paths.
Here’s the distinction that matters for everything after this section: CCMA performs a point-in-time transfer. It moves what exists at the moment you run it. It is not designed to keep environments aligned on an ongoing basis. Once the transfer completes, anything that changes afterward — on either side — is not CCMA’s concern anymore.
For a big bang migration, that’s fine: you run it once, cut over, done. For a phased migration, it means every phase you haven’t cut over yet is still live on Data Center, actively changing, while the phases you’ve already moved are live on Cloud, also actively changing. That’s the problem the rest of this playbook exists to solve.
Once your first phase cuts over, you have two live environments. Some teams are on Cloud. Some are still on Data Center. Both sides keep producing content — policy updates, project decisions, documentation changes — and none of it is automatically reflected on the other side.
This is true regardless of what tooling you use. A Cloud team updates a shared process page; the Data Center team working from the old version doesn’t know it changed. A Data Center team documents a decision the Cloud team needs; nobody thinks to copy it over until someone asks in a meeting why the Cloud version is missing it. The longer your migration takes — and multi-department phased migrations commonly run months — the further the two environments drift.
Some teams handle this manually for a phase or two: someone exports a page, someone re-pastes content into the other environment, someone spot-checks for differences before a cutover. It works at small scale. It does not scale across a six-month, six-department rollout — the reconciliation burden compounds with every phase you haven’t yet completed, and manual processes are exactly where things get missed.
This is the specific gap CCMA doesn’t cover, because it isn’t designed to. If you need Data Center and Cloud to stay genuinely in sync throughout a phased migration — not just at the moment of transfer — that’s what a continuous, bidirectional sync tool is for.
Space Sync for Confluence keeps content aligned across both environments for as long as you’re running hybrid, so teams on either side are working from the same current version, and each phase’s cutover starts from a state that’s already in parity rather than one that needs to be manually reconciled first.
Don’t cut a phase over on faith. Before each one:
Spot-check
Spot-check a sample of pages against the source, not just the page count.
Verify macro rendering
Migrated macros can silently break formatting even when the transfer technically “succeeds” — this is the most common thing that slips through unnoticed.
Confirm permissions carried over correctly
Especially for spaces with complex restriction structures.
Run a final parity check immediately before cutover
If you’re using a sync tool, this is a bulk sync checkpoint — bringing the phase’s spaces into full alignment right before the team’s access switches over, so what they find in Cloud is exactly what they left in Data Center, not a slightly-stale version from whenever the last sync happened to run.
Once a space is fully live in Cloud, it’s a natural point to clean house — archiving genuinely stale pages, fixing formatting issues the transfer may have introduced, and doing a bulk-edit pass rather than fixing things page by page.
This step happens on the Cloud side, by definition — the space now lives there. Tools built for bulk page management, like Pages Manager for Confluence, are useful here specifically because the content has already landed. Worth flagging clearly: Pages Manager for Confluence is Cloud-only, with no Data Center version, so it has no role earlier in this playbook — it’s a post-cutover cleanup tool, not a pre-migration one.
Only once every phase has cut over and been validated. Before you shut anything down:
“Done” looks like one environment, no more manual reconciliation between two versions of the truth, and the migration team standing down from active monitoring.
Worth keeping: whatever governance habits you built during the migration — a regular permissions review, an audit log check, a defined owner per space — even though the urgency that created them is gone. They’re generally good practice for any single-environment Confluence instance, migration or not.
If the phased-rollout parity problem in Section 5 is the piece of your migration you don’t have solved yet, that’s specifically what Space Sync for Confluence is built for.
