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.

Key differences

Let's look at the most important differences between the self-hosted and cloud versions in terms of terminology and capabilities.

Terminology
Self-hosted term Cloud term Notes
Content lifecycle configuration (archiving configuration) Scheme:
  • Content status scheme
  • Notification scheme
  • Automation scheme
 Self-hosted: Content lifecycle configurations group together a large number of related settings.
Cloud: Schemes are more isolated, with smaller responsibilities. Schemes can be mixed and matched for flexibility: for example, two spaces can use different content status schemes but share the same notification scheme.
Default archiving configuration Default scheme Cloud: You can set the default for each scheme type.
Archiving strategy Automation action Cloud: An automation defines when and what to do with which contents. Self-hosted "archiving strategy" 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: Jobs tend to be "more monolithic", where one job may handle multiple tasks.
Cloud: Jobs are "more atomic", with dedicated jobs for each specific task.
Blacklisted space Excluded space These terms are essentially the same.
Features

Global app settings refers to Confluence Settings (cog icon "⚙" in the top right) → Apps → Better Content Archiving.

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.

Self-hosted platform Cloud platform Description Docs
Content Quality
  • Site Dashboard
  • Space Dashboard
 Dashboards offer a wide range of statistics that allow you to assess the quality of your content on Confluence Cloud. Dashboards
Start Archiving
  • Global app settings → Jobs
  • Space app settings → Jobs
 The Jobs screen offers a clear interface to run jobs on the whole site or on a space. Jobs
Global Configurations Global app settings → Configuration The app is configured on a single, easy-to-understand screen. Configuration
Notification Emails Global app settings → Configuration → Notification configuration → Notification email templates Notification emails are configured independently in notification schemes.
Content Audit Log
  • Global app settings → Jobs → Job audit log
  • Space app settings → Job audit log
 Review results of the most recent jobs started either automatically or manually. Job audit log
Blacklisted Spaces Global app settings → Administration → Exclude spaces You can exclude spaces from content lifecycle management. Exclude spaces
Settings This screen has no direct equivalent in the cloud version
  • There is no "Trusted group" setting.
  • Default schemes can be set on the corresponding scheme config screens.
Page Status Indicator Content Status Indicator The Content Status Indicator is not available if the page is the home page of a space. View the content status
Scheduled Jobs (Confluence screen) This screen has no direct equivalent in Confluence Cloud The cloud version of our app has its own scheduled job implementation, you can use the Jobs screen to manage the jobs of the app.
Archiving configuration vs. schemes

Now that we covered the most important differences, let's look at how you can configure and use the cloud version of the app. We'll outline the differences in how you should approach setting it up compared to the self-hosted version.

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

Introducing schemes for more flexibility

On cloud, you can define schemes to configure 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. These 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.

The app comes with useful 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.

A note about default schemes

It is worth noting that you can apply the default scheme to a space implicitly and explicitly.

When applied implicitly, the space will always use the scheme that is set as default at the given time, which means that if you later set another scheme as default, all spaces to which the default scheme is applied implicitly will use the new default going forward. In other words, implicitly applying the default scheme means "look up the scheme that is set as default and use that one for this space".

In contrast, when applied explicitly, the space will always use that particular scheme, even if another scheme is set as default later. In other words, explicitly applying the default scheme means "always use this scheme for this space, regardless of whether it is the default or not".

When a new space is created, it is assigned the default scheme implicitly.

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.

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!
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.
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).

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.
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.
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.
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!

What is not 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.