In this page

Migrate from Confluence Server/Data Center to Confluence Cloud

This guide intends to provide fundamental guidelines to teams using Better Content Archiving for Confluence who are transitioning from a self-hosted (Server or Data Center) Confluence instance to Confluence Cloud. It aims to help you migrate your content lifecycle management strategies so that you can set up your new workflow to be as similar as possible to what you already established, while highlighting some useful new features that may help you make it even better.

The guide assumes that you are familiar with the self-hosted version of the Better Content Archiving for Confluence app, and outlines key differences in how to configure and use the same app built for Confluence Cloud.

Moving from archiving configurations to CQL based configuration schemes

On the self-hosted platform, archiving configurations coupled lifecycle management configuration options (like the archiving strategy) with notification settings. This approach covered the most important use cases, but it had certain limitations regarding flexibility.

The introduction of schemes is probably the most significant conceptual change in the cloud version, offering great flexibility for your workflow.

Introducing configuration schemes

On cloud, you can define configuration schemes to customize the app's behavior with regards to

  • how the statuses of your contents should be calculated,
  • how and when you want your notification emails to be sent,
  • and how and when you want the app to archive (on a paid Confluence Cloud plan) or delete contents in your Confluence Cloud instance.
Configuration schemes are completely decoupled from each other: for example, two spaces may share the scheme that defines how their content statuses should be calculated, while each using a separate scheme for notification emails or archiving automations.

Transitioning from traditional archiving configurations to modern configuration schemes is just the beginning. All schemes now leverage CQL expressions. As you may know, CQL is a robust and highly versatile query language integrated into Confluence. By migrating to CQL, you can customize content lifecycle rules with unparalleled flexibility.

The app already comes with pre-configured schemes that you can customize, and you can define your own ones as well. There is a default scheme for each scheme type, and you can explicitly apply the other schemes to spaces as you like. As you will see when opening the scheme configuration screen, you can configure a much more detailed and customized set of statuses that can be assigned to your contents, and you have fine-grained control over how and when each status should be assigned to a piece of content.

We designed this new workflow to maximize flexibility while still allowing you strict control over the app's features, without having to set up overly complicated rules. The factory-default set of schemes has been defined with the most common use cases in mind, and is meant to be a good starting point for teams with more specific needs.

Asynchronous behavior and jobs

The technical complexities of the cloud platform and the design choice to use CQL defined lifecycle rules have significant implications. On the self-hosted platform, content statuses were always up-to-date, but achieving the same consistency on the cloud is more challenging. To ensure you always have an up-to-date view of your data, content statuses are recalculated on every load of the content status indicator and at most within a few hours, for all content in your site. These recalculations are automatically scheduled, but you can initiate them manually at any time.

In summary, you don't need to worry—we handle the heavy lifting for you. However, some degree of asynchrony is inherent to the cloud platform, and it’s important to keep this in mind.

Key differences

Now let's review the most important differences between the self-hosted and cloud versions in terms of terminology and capabilities.

Terminology
Self-hosted term Cloud term Differences
Content lifecycle configuration (archiving configuration) Scheme:
  • Content status scheme
  • Notification scheme
  • Automation scheme
 Self-hosted: Content lifecycle configurations bring together all rules of lifecycle management (status calculation, notifications and archiving) into a single, compact configuration unit.
Cloud: 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: for example, two spaces can use different content status schemes but share the same notification scheme.
Default archiving configuration Default scheme Self-hosted: You can select a default archiving configuration. Cloud: You can select a default for each scheme type.
Archiving strategy Automation action Self-hosted: The strategy defines what to do with contents due for archiving. Strategy is tightly coupled together with notification settings in the same archiving configuration. Cloud: An automation specifies when, what actions to take, and which content to target, operating entirely independently of the app notifications sent. Self-hosted "archiving strategy" roughly corresponds to the Action field in automations.
Jobs:
  1. Analyze Content Quality
  2. Find and Archive Expired Content
  3. Persist the Content Update Journal
  4. Persist the Content View Journal
(All job names are prefixed with "Better Content Archiving".) 		Jobs:
  1. Refresh content statuses
  2. Send notifications
  3. Execute automations
  4. Initialize content events
 There is no 1:1 mapping between self-hosted and cloud jobs, but the names describe their responsibilities well.
Self-hosted: One job may perform multiple tasks (which is especially true for the "Find and Archive Expired Content" job).
Cloud: Jobs are more focused, with a single responsibility for each specific job.
Blacklisted space Excluded space These terms are essentially the same.
Features

With the new terminology in mind, let’s also examine the differences in feature sets between the self-hosted and cloud versions, and where each feature is located on the user interface.

Self-hosted platform Cloud platform Description
Content Quality Dashboards Dashboards offer a wide range of statistics that allow you to assess the quality of your content on Confluence Cloud.
  • Site Dashboard
  • Space Dashboard
Start Archiving Execute automations The Jobs screen offers a clear interface to run automation jobs on the whole site or on a space.
  • Global app settings1 → Jobs
  • Space app settings2 → Jobs
Global Configurations Configuration (schemes) The app can be configured on a single, easy-to-understand screen. To do that, go to: Global app settings1 → Configuration
Custom Configurations This feature has no direct equivalent in the cloud version You can apply configuration schemes to spaces in flexible way. To do that, go to: Global app settings1 → Configuration, choose a scheme type and use the "Apply to spaces" link.
Notification Emails Notification email templates

Notification emails can be configured independently in notification schemes.

To access them, go to: Global app settings1 → Configuration → Notification configuration → Notification email templates

Content Audit Log Job audit log Review 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. To do that, go to: Global app settings1 → Administration → Exclude spaces
Settings This screen has no direct equivalent in the cloud version Further differences on cloud:
  • There is no "Trusted group" setting.
  • Default schemes can be set on the corresponding scheme config screens.
Page Status Indicator Content Status Indicator View the content status in a similar but more feature-rich indicator. Further differences on cloud:
  • The Content Status Indicator is not available if the page is the home page of a space.
Scheduled Jobs (Confluence screen) This screen has no direct equivalent in Confluence Cloud The cloud version of Better Content Archiving app has its own job runner implementation. 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.

Step-by-step migration guide

This section outlines the recommended steps you should take when migrating your self-hosted Confluence instance to the cloud and configuring content lifecycle management with the cloud version of our app.

Step 1: Design your workflow

Decide on how you want the lifecycle of the contents of your spaces to be managed (content statuses, notification emails, and automated archiving/deletion):

  1. Look at the docs of the cloud version of the app and understand the configuration options.
  2. Review your current archiving configurations.
    1. Hint: this is a good time to think about any improvements or changes to your workflow that you would want to implement anyway.
  3. Think about how you can translate your configurations defined in the self-hosted version of the app to the scheme-based philosophy of the cloud app. You can look at the preconfigured schemes for inspiration (see also below), and check out the tutorials and best practices in the docs!
    1. Remember that on cloud, content status schemes are not coupled with notification schemes and automation schemes; these three are totally independent. For example, if you have two configurations that assign content statuses differently but have the same notification settings, that means you only need one notification scheme for the same notification workflow on cloud!
Step 2: Install and initialize the cloud app

After installing the cloud version of the app, perform the following initial steps:

  1. Wait a bit: the Initialize content events job will be run automatically, in 5 minutes after installation.
  2. Verify that all Integrity checks pass.
  3. Verify permissions on the App space permissions screen.
Step 3: Exclude spaces as needed

Exclude the spaces in which lifecycle management is not needed (this works exactly the same way you blacklisted spaces on the self-hosted platform).

Step 4: Set up content status schemes
  1. Look at the preconfigured content status schemes and content statuses, and understand how they work.
  2. Based on your unique needs, decide how many different schemes you need, then fine-tune the preconfigured schemes or create new ones as needed.
  3. Decide which scheme you want to use most often (in most spaces and/or in new spaces you will create going forward) and make it the default scheme.
  4. If needed, apply any non-default scheme to the spaces you want to use them in.
Step 5: Set up notification schemes
  1. Look at the preconfigured notification schemes and email templates, and understand how they work.
  2. Customize them as needed:
    1. The syntax of notification email templates differs significantly compared to the self-hosted app version (on cloud, Handlebars is used in the templates instead of Velocity), so you will have to re-write your templates if you have specific needs. You can use the preconfigured ones as a starting point, and you can also look at our docs for details, tips, and practices.
    2. Hint: you can disable notifications in a scheme (a scheme may contain more than one notification, these can be enabled or disabled separately).
  3. Set the default scheme and apply any other schemes to spaces as needed.
Step 6: Set up automation schemes
  1. Look at the preconfigured automation schemes, and understand how they work.
  2. Customize them as needed.
    1. Hint: you can disable automations in a scheme (a scheme may contain more than one automation, these can be enabled or disabled separately).
  3. Set the default scheme and apply any other schemes to spaces as needed.
Step 7: Explore new features

Explore app features available on cloud only, like macros or the sophisticated reporting features of the dashboards, to get the most out of our app!

Limitations of migration (list of things that cannot be migrated)

There are a few limitations when it comes to migrating to cloud.

  1. Content view events can not be migrated. The cloud app initializes these values with sensible defaults after installation, and from there, they will get populated organically as your team interacts with your content.
  2. Archive spaces created by the self-hosted version of the app and migrated to your Confluence Cloud instance won't be regarded as an archived version of a live space anymore. On cloud, there is no "archive space" managed by the app for a live space – the app uses Confluence Cloud's built-in content archiving feature instead, leaving the content in its original space.

Questions?

Ask us any time.