In this page

Migrate from Confluence Server/Data Center to Confluence Cloud

This guide offers instructions for teams migrating from the self-hosted (Server or Data Center) Better Content Archiving app version to the cloud. It helps you adjust your content lifecycle management processes, keeping your workflows similar to your current setup while introducing new features to improve them.

It assumes you are familiar with the self-hosted version of Better Content Archiving and points out important differences in configuration and usage on Confluence Cloud.

How to read this guide

Migration is a complex task and can be approached from different angles. We’ve broken it down into three main chapters. We recommend reading them in order, but you’re welcome to skip to any section that interests you:

  1. Overview (this page): Key differences, design decisions, terminology changes, and how major features have been relocated in the UI.
  2. Changes in depth: A more detailed look at the changes. This serves as a reference guide with categorized, yet loosely related topics, focusing on even the smaller details.
  3. Step-by-step instructions: By this point, you’ll be familiar with the cloud version. This part provides a clear, executable plan for carrying out the migration process.

Overview

Migrating from the self-hosted version to the Cloud involves more than just moving data. It means adapting to a platform with different design principles, asynchronous behavior, and a revised feature set.

While core functionality remains, many features have been reimagined or relocated, and some familiar terms have changed to better fit the cloud environment. Understanding these differences will help ensure a smoother transition and more effective use of the cloud app.

Understanding key differences

Let's begin with a brief overview of the design decisions behind the cloud version of the app.

These changes were necessary to align with the cloud platform’s architecture and API, and to deliver a better overall user experience. We also used this opportunity to expand the app’s capabilities and add new features that weren't possible in the self-hosted versions.

Understanding these key differences will help you see how and why the cloud version of the app has changed, both in features and limitations.

Introducing flexible configuration schemes

In the self-hosted versions, archiving configurations combined content status settings and notification settings into a single unit. While this was simple, it limited flexibility.

The cloud version introduces a major shift with the concept of configuration schemes. Instead of one combined setup, there are now separate schemes, each with a specific focus:

Note that these configuration scheme types are independent of each other. For example, two spaces may share the same content status scheme but use different notification or automation schemes.

The app provides sensible default settings for each scheme type, so you can get started quickly. You can adjust these defaults to meet your specific needs or create entirely new schemes to match your workflows.

This modern approach offers greater flexibility and customization. By separating the configuration schemes, you can mix and match them to build the ideal workflows for your team!

Building rules with CQL expressions

Another key difference in the cloud version is the use of CQL searches as the basis for all features that require flexible filtering.

Unlike the self-hosted app version, which provided only a limited set of predefined controls and boolean operators for configuring lifecycle rules, CQL is a powerful, full-featured query language integrated into Confluence. You can fully leverage its capabilities to create custom lifecycle rules!

As an important result, standard Confluence labels are no longer heavily used to control lifecycle management on cloud. They are not required — but they are still fully supported and can be used effectively, since CQL supports label-based filtering.

Moving from labels to CQL is a major improvement and unlocks new possibilities. It allows you to build advanced queries to filter and manage pages, blog posts, and other content with much greater precision than before.

Asynchronous by nature

In the cloud, many actions that were previously synchronous in the Data Center version are now handled asynchronously. This shift improves performance and scalability but may require a slight adjustment in how you interact with the app.

For example, in the self-hosted platform, content statuses were updated in real-time, ensuring they were always up-to-date. In the cloud, statuses are updated asynchronously, which may result in slight delays between content changes and status updates. To minimize delays, the app recalculates statuses every time the Content Status Indicator is displayed and ensures all statuses are refreshed within a few hours. You can also manually trigger recalculations by starting the Refresh Content Statuses background job.

This asynchronous approach balances performance with resource usage, and the app handles most of the complexity for you. Keep in mind that some delay is expected due to the nature of the cloud platform.

Mapping terminology and features

Now that you understand the key changes, this section outlines the differences in terminology between the self-hosted and cloud versions of the Better Content Archiving app. It also introduces a table for quick reference, making it easy to locate the features you're familiar with from the self-hosted version in the cloud app.

Terminology changes

As you transition to the cloud version, some terms may differ from those used in the self-hosted version. This section explains these changes in terminology to help you easily adapt to the cloud app’s vocabulary.

Self-hosted term Cloud term
Page status Content status

On the cloud, we use this broader term because pages are no longer the only supported content type.
Content lifecycle configuration / archiving configuration

Content lifecycle configurations bring together all rules of lifecycle management (status calculation, notifications and archiving) into a single, compact configuration unit. 		Configuration scheme (general term), which can be one of the following:
Schemes provide greater flexibility by breaking down the loosely connected aspects of lifecycle management into more focused and reusable configuration units. Schemes can be mixed and matched freely.
Default archiving configuration

You can select a default archiving configuration. 		Default scheme

You can select a default for each scheme type.
Archiving strategy

The strategy defines what to do with contents due for archiving. 		Automation action

An automation specifies when, what to do on which content. It is a broader concept, in which the self-hosted "archiving strategy" roughly corresponds to the cloud automation's Action field.
Jobs can be one of the following: (All job names are prefixed with "Better Content Archiving", which we omitted here.)

One job may perform multiple tasks. (It is especially true for the "Find and Archive Expired Content" job.)
 Jobs can be one of the following: There is no 1:1 mapping between self-hosted and cloud jobs, but the names describe their responsibilities well. Cloud jobs are more focused, with a single responsibility for each specific job.
Blacklisted space

A space excluded from content lifecycle management. 		Excluded space

This term is essentially the same, with a more straightforward name.
New locations of familiar features

While many core features are still available in the cloud version, their locations within the app or Confluence interface may have changed. This section helps you quickly locate the familiar features, so you can continue working seamlessly.

Self-hosted feature Cloud feature Location and notes
Content Quality Statistics Dashboards Dashboards offer a much wider range of statistics and KPIs on your content in two scopes.
  • Site Dashboard (main Apps menu → Better Content Archiving)
  • Space Dashboard (accessible from each space's navigation bar)
Start Archiving Execute automations You can run the Execute Automations job in two scopes.
  • Global app settings1 → Jobs
  • Space app settings2 → Jobs
Global Configurations Configuration schemes You can configure the app on a single, easy-to-understand screen.
  • Global app settings1 → Configuration
Custom Configurations No direct equivalent You can apply configuration schemes to spaces in flexible way.
  • Global app settings1 → Configuration → choose a scheme type → click Apply to spaces
Notification Emails Notification email templates You can configure notification email templates together with notification schemes.
  • Global app settings1 → Configuration → Notification configuration → Notification email templates
Content Audit Log Job audit log You can view the job execution results of the most recent jobs started either automatically or manually.
  • Global app settings1 → Jobs → Job audit log
  • Space app settings2 → Job audit log
Blacklisted Spaces Exclude spaces You can exclude spaces from content lifecycle management.
  • Global app settings1 → Administration → Exclude spaces
Settings Global settings You can change global app settings.
  • Global app settings1 → Administration → Global settings
Page Status Indicator Content Status Indicator While the location remains the same, the cloud equivalent offers enhanced functionality.
Scheduled Jobs
(Built-in Confluence administration screen) 		No single equivalent, see notes The cloud version implements its own job runner, fully independent of Confluence's built-in scheduling system. You can execute jobs manually on the Jobs screen. The execution history is available in the Job audit log.

Legend:

  1. Global app settings refers to Confluence Settings (cog icon "⚙" in the top right) → Apps → Better Content Archiving.
  2. Space app settings refers to opening Space settings in any space, and then selecting Integrations → Better Content Archiving. This screen is not available in excluded spaces.

Questions?

Ask us any time.