This story didn't start with Simple Metadata.
It started with a customer.
A large enterprise organization was already using Simple Tables when they came to us with a very different problem. They were preparing to move a very large Confluence environment from Data Center to Cloud.
And when I say large, I mean large.
Their Confluence environment contained approximately 2,000 spaces and more than 2 million pages.
Within that environment, they also had thousands of pages built around Page Properties. Over the years, those properties had become an important part of how information was structured and reported across Confluence.
Page Properties had served them well. The problem wasn't that they wanted to get rid of them.
The problem was what happens when you try to migrate and govern something at that scale.
They needed to bring all that information to Cloud without manually rebuilding thousands of pages. But they didn't want their Cloud migration to simply recreate the same Page Properties architecture they had built over the years. They wanted the migration itself to become an opportunity to move to a governed metadata model.
At 2,000 spaces and more than 2 million pages, a process that requires someone to manually inspect, recreate or maintain metadata page by page simply isn't a migration strategy.
That requirement ended up having a major influence on a product we were already working on: Simple Metadata.
With the customer's permission, we're sharing this particular use case while keeping the organization anonymous.
And rather than explaining the result first, here's a smaller demonstration of exactly the problem we needed to solve.
π₯ Watch: Migrating 1,000 Confluence pages from Page Properties to structured metadata
The video uses 1,000 pages because it's an easier way to demonstrate the process.
The real environment that helped shape the approach was considerably larger.
This isn't just a macro replacement. It's a migration from independently maintained Page Properties tables to a controlled metadata model built around schemas, field types, validation, history and reporting.
And that's where this story gets interesting.
Page Properties weren't the problem
This is important.
Page Properties have been one of those beautifully simple Confluence ideas. Add a small table to a page, put some information in it, and use Page Properties Report to bring information from multiple pages together.
Our customer had done exactly that.
Over time, however, thousands of pages had been created around the model. What began as Page Properties had effectively become part of the organization's data architecture.
And that's a very different problem.
Imagine thousands of pages containing something like:
Property | Value |
|---|
Owner | Mia Tamm |
Status | Active |
Risk | Medium |
Review date | 2026-12-01 |
Now imagine needing to change the model.
A new Data Classification field is required. Owner should become mandatory. Risk should only accept Low, Medium, High or Critical. Review Date should actually be a date. New pages should start with a predefined Status.
At enterprise scale, making those changes isn't really a table-management problem anymore.
It's a data-model problem.
And simply recreating thousands of Page Properties in Cloud would also recreate the limitations that came with them.
So we approached the migration differently
The requirement became relatively clear.
We needed to preserve the value of the information the organization had already created, while moving it into a model that could be managed centrally going forward.
And at the scale we were dealing with, automation wasn't a convenience. It was a requirement.
That became one of the key principles behind the Page Properties migration in Simple Metadata.
The importer can discover existing Page Properties, analyze their structure, create schemas from them and migrate their existing values into structured metadata.
But importing the values wasn't enough.
Simple Metadata can also replace the existing Page Properties macro on the migrated pages with the corresponding metadata schema.
That distinction matters.
The result isn't thousands of pages with their data copied somewhere else while the old structure remains behind.
The pages themselves move to the new model.
That's what we're demonstrating with the 1,000-page migration in the video above.
The real enterprise problem wasn't importing some values. It was doing it in a way that could become the foundation for what came next.
The migration isn't the destination. It's the bridge.
Migrating thousands of pages is only half of the job
Once the existing content has been migrated, there's an obvious next problem: what happens when somebody creates the next page?
If users continue creating pages from templates containing the old Page Properties macro, you've successfully migrated the past while continuing to create the same architecture in the future.
So the new metadata schema can also become part of the Confluence template used to create those pages.
From that point forward, new content starts with the same controlled metadata model: the correct fields, field types, required values, defaults and available options.
The migration therefore has two sides.
Existing content is brought into the new metadata model.
New content is created using that model from day one.
This was particularly important for the kind of enterprise use case that led us here.
A migration is useful.
A migration that leaves you with a maintainable system afterwards is much more useful.
This is where schemas change things
Once thousands of independent tables become instances of a schema, managing the information changes considerably.
Need another field? Add it to the model.
Need Owner to be required? Define it as required.
Need Risk to use controlled values? Define those values.
Need a default? Define it once.
Instead of asking thousands of pages to independently maintain the same structure, you have a data model that describes what that metadata is supposed to look like.
And once the information follows that model, you can search it, filter it, group it, bulk update it, report on it and export it consistently.
The progression is quite simple:
Page Properties β Metadata β Data β Insights
Confluence is still Confluence. The pages remain pages.
But the information distributed across them becomes something you can manage as data.
And every change has a history
For the kind of enterprise environments we're talking about, having the current value isn't always enough.
You may also need to know how you got there.
Once content is managed through Simple Metadata, changes to that metadata are recorded in its history.
That gives organizations a record of how values have evolved over time rather than simply replacing one value with another and losing the previous state.
And when that information is required for an audit, internal review or another governance process, the history can be exported.
This is one of the reasons we see structured metadata as something substantially different from simply making Page Properties more sophisticated.
You're not only defining information.
You're beginning to govern it.
This becomes particularly important for compliance
Consider ISO 27001, SOC 2, GDPR or an internal governance framework.
Having information documented is only part of the challenge. Organizations also need consistency and traceability.
An owner should actually be defined. A classification should use an accepted value. A review date should be a date. Required information should remain required.
And when information changes, having a history of those changes can become just as important as the current value.
A Page Properties table can absolutely contain compliance-related information.
A structured metadata model gives you a way to manage that information as controlled data.
That distinction becomes increasingly important at enterprise scale.
And the data stays within Atlassian
There was another architectural consideration that mattered to us when building Simple Metadata for this kind of environment: where the information lives.
Simple Metadata is a Runs on Atlassian app.
For anyone unfamiliar with the designation, Runs on Atlassian means eligible app data is stored and processed within Atlassian's infrastructure rather than requiring an external application backend operated by the Marketplace vendor.
For a metadata system, that's particularly relevant.
Schemas, metadata values and the information used to manage them remain within the Atlassian platform.
Moving from Page Properties to structured metadata therefore doesn't require moving your Confluence metadata into another vendor's external system.
Your Confluence data stays in Atlassian.
For enterprise organizations evaluating governance, security and compliance requirements, we believe that should be part of the architecture rather than an afterthought.
Exporting the data opens another door
Once information is consistently structured, exporting stops being a workaround and starts becoming genuinely useful.
Metadata distributed across thousands of Confluence pages can become a dataset that can be analyzed, audited, processed and reported.
You can look for patterns instead of individual pages. You can identify missing information across an entire set of documents. You can compare data that was previously scattered across Confluence.
And you have two complementary datasets available when needed: the current structured metadata and the history of how that metadata has changed.
This is also where we think things will become increasingly interesting as AI changes how organizations work with knowledge.
AI can do a lot with documents.
But predictable, structured metadata gives those documents context.
What about other Data Center migrations?
The enterprise use case that influenced this work started with Page Properties, but that's obviously not the only way organizations have managed metadata in Confluence Data Center.
Some organizations have sophisticated metadata models built with other apps or internal solutions.
We're working on this problem too.
Simple Metadata can use JSON and YAML to define and manage schemas and structured metadata, which creates another possible path for bringing existing metadata models into Confluence Cloud without manually rebuilding everything.
That's a considerably bigger subject, so I'm going to leave it for another article.
I'd like to write specifically about Data Center β Cloud metadata migrations, including how JSON and YAML can be used as part of that process.
The underlying principle is the same one we learned from this case:
Migration shouldn't mean starting again.
Page Properties were the beginning
This project actually made us appreciate Page Properties more, not less.
Their simplicity allowed organizations to build systems inside Confluence that probably went far beyond what anyone originally imagined.
The difficulty appears when those systems reach enterprise scale and need stronger control, validation, governance, history and reporting.
That's the transition Simple Metadata is designed to address.
For the customer that helped shape this use case, the challenge existed inside a Confluence environment of approximately 2,000 spaces and more than 2 million pages.
That scale matters because it changes the nature of the problem. Manual migration isn't merely inconvenient. It stops being realistic.
For us, the challenge became building a robust path forward:
- Existing pages β discover and migrate their Page Properties, then replace the macro with structured metadata.
- New pages β include the schema in the Confluence template so new content follows the model from day one.
- Ongoing governance β manage field types, required values, defaults and controlled options centrally.
- Traceability β maintain a history of metadata changes that can be exported when needed.
- Security architecture β keep eligible app data within Atlassian through Runs on Atlassian.
- Reporting and analysis β turn information distributed across thousands of pages into structured data that can actually be used.
That's ultimately what came out of a customer asking us how they could migrate thousands of Page Properties.
Not simply another way to display metadata.
A way to move from Page Properties to a controlled metadata system without throwing away the work that came before it.
I'm Mia Tamm, part of the team behind Simple Metadata for Confluence at Simpleasyty.
The enterprise use case described in this article is shared with the customer's permission, but we've intentionally kept the organization anonymous. They were already users of Simple Tables, and their Data Center migration requirements helped us shape the Page Properties migration capabilities in Simple Metadata.
Their overall Confluence environment included approximately 2,000 spaces and more than 2 million pages. The 1,000-page example in the video is a smaller demonstration designed to show how the migration process works.
You can find Simple Metadata for Confluence on the Atlassian Marketplace.
I know this has been a fairly dense article. The reason is simple: this isn't a small change when you're dealing with an enterprise Confluence environment at this scale.
If your organization has a similar Page Properties setup, is planning a Data Center migration, or simply wants to understand what moving to structured metadata would involve, you can contact us through our Simpleasyty support portal.
We're happy to look at the existing setup and discuss the migration with you.
π Contact Simpleasyty Support
