Metadata for Confluence: A Forge-Compatible Full Automated Cloud Migration

[#1]

Hello there!

I'm Elena from Elevatic. If you've ever migrated an app from Data Center to Cloud, you know the quiet dread: what happens to all the structure woven through your content?

For Metadata for Confluence, that dread just got a lot smaller. In this article, I explain how.

---

TL;DR

Migrating Metadata for Confluence from Data Center to Cloud no longer means rebuilding your metadata structure by hand: your global Metadata set and field definitions now convert automatically into Content Categories in Cloud during migration — no manual recreation needed. The migration path is now Forge-compatible, aligning your move with Atlassian's current platform standards, and a reworked onboarding experience helps new Cloud users get started faster. If a move to Confluence Cloud is on your roadmap, this is the release that removes one of its biggest manual chores.

If a Data Center to Cloud move is on your roadmap, you already know the migration itself is rarely the hard part. The hard part is the long tail — the structure woven through your content that all has to make the trip intact. Metadata is squarely in that category: the sets, fields, and definitions behind your classification, tagging, and governance that your teams rely on every day.

For a long time, the metadata layer was one of the parts of that move you had to rebuild by hand on the other side. Not anymore.

Your global metadata migrates itself — as Content Categories

The headline change: when you migrate from Data Center to Cloud, your global Metadata set and field definitions are now converted automatically into Content Categories in Confluence Cloud.

Here's what that means in practice. The migration creates — or reuses, where a match already exists — the Content Categories that correspond to your global Metadata set definitions. So the metadata structure your teams depend on arrives in Cloud already in place, mapped to the Cloud-native model, without anyone rebuilding it by hand.

That matters because this was historically the most manual, error-prone part of the whole move. Recreating metadata sets and fields one by one before migration is tedious on a small instance and genuinely painful on a large one, where a single definition can touch content across hundreds or thousands of pages. Getting it slightly wrong means classification and governance quietly break in the place your teams look first. Automating the conversion takes that risk — and that work — off your plate.

No manual recreation needed. That's the short version, and this release makes it true.

A Forge-compatible migration path

The migration path for Metadata for Confluence is now Forge-compatible.

A quick word on where the app stands. Metadata for Confluence already runs largely on Atlassian's Forge platform — the modern, secure foundation Atlassian is steering the whole Marketplace toward. This release advances that direction by making the migration path itself Forge-compatible, so the way your content moves into Cloud aligns with Atlassian's current standards.

Why that matters: Forge apps run natively inside Atlassian's own infrastructure rather than on external vendor servers, which is the foundation of the "Runs on Atlassian" model — your data stays on the Atlassian platform, and security and compliance are handled centrally. As Atlassian phases out the older Connect framework through Q4 2026, a Forge-compatible migration path means you're moving toward the platform Atlassian is actually investing in.

If you want the full picture of the deadlines and platform direction, Atlassian's own Connect end-of-support guidance is the primary source worth bookmarking.

A smoother start on Cloud

Landing your data cleanly is only half of a good migration; the other half is what the experience feels like once you're there. This release also reworks the onboarding experience, so teams arriving on Confluence Cloud get oriented and productive faster — less time spent figuring out where things are, more time using them.

Key Takeaway

Treat app migration as part of your platform migration, not an afterthought. The apps carrying your metadata, classification, and governance are load-bearing — if their structure doesn't come across cleanly, your content breaks exactly where teams notice first.

This release removes that risk for Metadata for Confluence: your global metadata sets and fields convert automatically into Content Categories as you migrate, the migration path is Forge-compatible, and onboarding is smoother on arrival.

---

Planning a move to Confluence Cloud and want the metadata layer to survive it intact? Metadata for Confluence now offers a Forge-compatible migration path with full automated migration built in. 

[Zulfkar Ali]

This a big quality-of-life improvement for Confluence migrations, auotmatically carrying metadata into Ccontent Categories could save terms a ton of manual cleanup. The Forge-compatible path is a nice bonus too.

[Mia Tamm _Simpleasyty_]

Really interesting update @Elena_Elevatic. One of the hardest parts of a Data Center → Cloud migration is often not moving the content itself, but preserving all the structure and conventions teams have built around that content over the years.

That’s why the automatic conversion into Content Categories stood out to me. Removing the need to manually recreate that structure can potentially eliminate a lot of tedious work, but also reduce the risk of losing consistency during the migration.

I also think the Forge-compatible path is important here. Migration projects already have enough moving parts without introducing another platform concern into the mix.

Nice work and thanks for explaining not just what has changed, but why it matters during a real migration.

[Karl from Ricksoft]

Hi @Elena_Elevatic 

Great writeup! automatically converting global Metadata sets into Content Categories on migration removes one of the more tedious manual steps.

One thing worth flagging alongside it: metadata surviving the move solves the classification/governance layer, but the content underneath the actual spaces and pages  usually can't cut over in one shot either. Enterprise Confluence Data Center migrations commonly run 3-12 months once you factor in pilot testing and parallel operation (per MassiveGRID's DC end-of-life guidance), which means teams need both environments staying usable and aligned for most of that window, not just synced once at final cutover.

That's the layer Space Sync for Confluence focuses on  bidirectional auto-sync between your DC and Cloud spaces throughout the migration, plus bulk sync for the initial move and sync-status visibility so you know what's still behind. (Disclosure: I work on Space Sync for Confluence at Ricksoft, so take the product mention with that in mind.)

Start your 30-day free trial on the Atlassian Marketplace.Running a large-scale DC-to-Cloud migration and want to talk it through first? Book a demo with our team.

[Elena_Elevatic]

Thanks, @Zulfkar Ali! That's exactly the goal — cutting down the manual cleanup that usually comes with metadata during a migration. Glad the Forge-compatible path stood out too, that was an important design choice for us.

[Elena_Elevatic]

Hi @Mia Tamm _Simpleasyty_ Thank you, really well put. You're right that the hardest part is often preserving the structure and conventions around the content, not just the content itself. That's the gap we wanted to close with the automatic conversion into Content Categories, so teams don't have to rebuild that structure by hand and risk losing consistency along the way.

Appreciate you taking the time to write such a thoughtful comment.

[Elena_Elevatic]

hey @Karl from Ricksoft Thanks for the detailed comment. You're right that metadata and content are two different layers of a migration, and our feature focuses specifically on the metadata/classification side. For long-running migrations where DC and Cloud need to stay in sync throughout, having a dedicated solution for that layer makes sense. Appreciate you sharing the context on Space Sync, and thanks for the disclosure.