Use Confluence Cloud Migration Assistant to migrate (legacy)

The Confluence Cloud Migration Assistant is an app that helps you easily move content, users, and groups from Confluence Server or Data Center to Confluence Cloud. Built and maintained by Atlassian, the app is free to install and use.

With the app, you can choose what you want to move to the Cloud, start migrating at your convenience, and monitor the progress of everything throughout the migration process.

When to use the Confluence Cloud Migration Assistant

Use the Confluence Cloud Migration Assistant when:

• you want to move users or data from Confluence Server or Data Center to Confluence Cloud

• you want to assess your apps before moving from Confluence Server or Data Center to Confluence Cloud

• you want to run a test or trial migration from Confluence Server or Data Center to Confluence Cloud

• the Atlassian Support team has recommended using the app

Install the Confluence Cloud Migration Assistant app

If your Confluence Server site is version 6.13 or above you won't need to install anything as the Confluence Cloud Migration Assistant comes pre-installed, although you may be asked to update the app. 

To install the app on versions 5.10 to 6.12:

1. In Confluence Server, go to > Manage apps.

2. Choose Find new add-ons. 

3. Search for the Confluence Cloud Migration Assistant. 

4. Choose Install and you're all set.

Locate the Migration Assistant

To find the Migration Assistant:

1. Go to Confluence Administration > look for the Atlassian Cloud category > select Migration Assistant.

There are four steps to create your migration path:

1. Assess your apps

2. Prepare your apps

3. Review all email domains

4. Migrate your data

The sections that follow explain each of these stages in detail.

If you have no apps to migrate, you can skip to step 3.

The sections that follow explain each of these stages in detail.

1. Assess your apps

Use the Confluence Cloud Migration Assistant to see the apps you’ve installed on your Server and assess apps in preparation to migrate. Assessing your apps and choosing alternatives (if required) for your Cloud site before migration removes the risk of your apps blocking your migration at a crucial time. Learn how to assess apps

To begin assessing your apps:

On the Migration Assistant home screen, select Assess your apps. Learn more about assessing apps with the Confluence Cloud Migration Assistant

When you have finished assessing your apps, select Done. This takes you back to the Migration Assistant home screen where you can choose to prepare your apps as the next step.

2. Prepare your apps

There are three main tasks you’ll perform at this stage:

• connect to your Cloud site

• install your apps

• agree to app migration

On the Migration Assistant home screen, select Prepare your apps. This takes you to the Connect to cloud screen.

2.a. Connect to your Cloud site

You can link your chosen Cloud site at this step. There are three ways to do this:

• select your existing Cloud site from the dropdown

• signup for an Atlassian Free plan (max 10 users, free Cloud site)

• set up a free product trial

Once your destination is selected, click Continue.

2.b. Install your apps

On the Install your apps screen:

1. Select Install app for each listed app to install it on your Cloud site.

2. Read the support and privacy policy for each app.

3. Select Continue. This takes you to the Agree to app migration screen.

2.c. Agree to app migration

In order to complete the assessment flow, you must provide consent and agree to app migration for each app.

On the Agree to app migration screen:

1. Select View policy for each app that shows as requiring your consent.
   This opens a card that:

   1. lists all the types of data the Marketplace Partner (vendor) will have access to, such as read core data or read user data.

   2. links to the Atlassian Marketplace Terms of Use, the Marketplace Partners Privacy Policy, and the Marketplace Partners Terms of Use. We strongly recommend you read this for each app you migrate.
      
      

2. Select Confirm on this card.

3. When you have performed the above action for all applicable apps, select Done to return to the Migration Assistant home screen.

You can find detailed information the third-party migration agreement in the section that follows.

Third-party migration agreement

When an app migration is performed, the migration moves the data from each Server app to its Cloud version on your Cloud site. The Marketplace Partner (vendor) that built each app has created a migration pathway to move the data.

During this process, the Marketplace Partner will actually be performing the app data migration, not Atlassian. Because of this, you need to review, and agree to each Marketplace Partner agreement so they can access your data to migrate it.

The Marketplace Partner (vendor) that built each app has created a migration pathway to move the data, via the Atlassian platform known as the App migration platform.

It is very important to understand that the Marketplace Partner (vendor), who developed a particular app, will be performing the data migration. Atlassian has developed the App migration platform to be the conduit between the Marketplace Partner and yourself as the app user.

Data security and allowed access scopes

The App migration platform allows Server apps to export your app data to Cloud, and to access Confluence and Jira mappings. The access is very tightly controlled and restricted to a list of data types, or access scopes.

• The Marketplace Partners who built the apps installed on your Server instance, have documented the access scopes required to migrate the apps.

• These access scopes are surfaced in the Cloud Migration Assistant so that you can consent to the Marketplace Partner accessing this data.

You can find the specific information and list of access scopes on the Security and Access scopes pages in Atlassian’s developer documentation. For more context, read the data privacy guidelines for developers that Atlassian recommends.

Agreeing to a migration

Each Marketplace Partner app has different access scopes. You must review and agree to each Marketplace Partner agreement before they can access your data to migrate.

It’s important to know that:

• only an app with an automated migration path needs you to agree to the migration

• if you agree to third-party migration, you can revoke your agreement at any time

• if you don’t agree to third-party migration, that app can't be migrated using the Confluence Cloud Migration Assistant

• if a Marketplace Partner updates an app, you will need to agree to the migration again

• after you agree to app migration, you can still select Revoke agreement. This will remove your agreement to third-party data migration. To agree again, click View policy and re-confirm your agreement.

Once this is ready, you have completed your app assessment. Click Done to return to the homepage.   

Some quick notes on this table:

• Atlassian’s Cloud Terms of Service and Privacy Policy do not apply to any apps installed on your Cloud site.

• By installing apps on your Cloud site, you agree to the Atlassian Marketplace Terms of Use and the Marketplace Partners privacy policy and terms of use.

• You should review a privacy policy in detail before installing an app in your Cloud site. 

• You can find the privacy policy and terms of use for each app on the app listing in Atlassian Marketplace.

App migration agreement status messages

When you click View policy, you will see a modal that lists the following:

• Access scope of that particular Marketplace Partner

• All the information they will need to access/see in order to migrate this app

There are three links in each modal:

• Atlassian Marketplace Terms of Use (the same for each app)

• The Marketplace Partner Privacy Policy (unique to each app)

• The Marketplace Partner Terms of Use (unique to each app)

We strongly recommend you read each one for each app.

Once this is ready, you have completed your app assessment.
Select Done to return to the homepage.

Pre-migration checks for possible data conflicts in your Cloud site

You can reduce the risk of running into issues, or the migration failing, if you conduct some manual checks in your Server and Cloud sites.

1. Check for group conflicts

Make sure that there are no groups already in your Cloud site with the same name as groups from your Server site, unless you are intentionally trying to merge them.

If we find a group in your Server site that has the same name as a group in your Cloud site (either Jira or Confluence), we will merge the users from the Server group into the Cloud group. The Server group users will inherit the permissions of the Cloud group. This also applies to groups with Jira product access that have the same name as a Confluence group you are migrating. This is because all users and groups are managed in a central location in your Cloud site.

If you don’t want this to happen, you’ll need to make sure all groups across Server and Cloud have unique names before running your migration.

The following groups manage admin access and are blocklisted. They will not be migrated at all:

• site-admins

• system-administrators

• atlassian-addons

• atlassian-addons-admin

Users in these groups will still be migrated, so if you want them to be in one of the blocklisted groups you’ll need to manually add them after migration.

2. Check for space key conflicts

Before migrating, check that there are no spaces with the same space key between your Server and Cloud sites.

If a space from your Server site has the same space key as a space in your Cloud site your migration will fail. This is because every space in Confluence Cloud must have a unique space key. If you find a conflict you can:

• delete duplicate spaces from your Cloud or Server sites

• reset your Cloud site

• choose not to migrate these spaces

If the migration assistant finds a conflict, the space will not migrate.

If a space key conflict is caused by a previous test migration you can reset your cloud site before migrating. Learn how to reset your Confluence Cloud site

3. Review all email domains

Before you migrate, you must review your users' email domains to prevent migrating users from email domains you don’t recognize or trust. This improves the security of your Cloud site. The domains you select here will be applied to all your future migrations.

You can start reviewing your domains from the Migration Assistant home screen. Select Review all email domains. This will take you to the Review all email domains screen.

This screen lists all your email domains with the number of users in each domain. You need to mark all your domains as trusted. This ensures that you migrate users only from the email domains you trust.

For each listed domain, you need to make one of the following three decisions:

You’ll need to review all your email domains and mark them as trusted. You can continue your migration without trusting all the domains, but you won’t be able to run the migration.

Once you've marked all your domains as trusted, select Done to complete the domain review and return to the Migration Assistant home screen.

If you've any previously saved migrations:

1. From the migration dashboard, you can either create a new migration or run an existing migration. A message appears telling you to review your email domains.

2. Select Review domains to review all your email domains and mark them as trusted.

3. Select Continue without reviewing if you want to review your domains later. You can continue without trusting all the domains at this stage, but you won’t be able to run the migration.

4. Migrate your data

There are five key steps to set up and run your migration from Server or Data Center to Cloud. They are:

1. Connect to cloud

2. Choose what to migrate

3. Check for errors

4. Review your migration

5. Migrate

The sections below describe each step in detail and explain some common errors that you may come across.

To begin migrating your data:

1. On the Migration assistant home screen, select Migrate your data. This takes you to the Migrations dashboard.

2. Select Create new migration. This takes you to the How it works screen.

3. Review the information on this screen, and select Connect to Cloud to continue.

4.a. Connect to your cloud site

You’re asked to specify a name for your migration, select your migration tag from the Choose migration stage menu (production or testing), and then select which cloud site you want to migrate to. You must be an:

• admin in your server instance.

• organization admin and a product admin in the Confluence Cloud.

If you’ve already connected a cloud site, you should see it in the dropdown. If there is nothing there, you will need to either connect to a new cloud site or sign up for a new cloud license.

When you’re ready, select the checkbox to allow Atlassian to move your data from your server site to your cloud site. If you can't grant Atlassian this access, you won’t be able to migrate with the migration assistant and will need to do a space import instead.

If your Confluence Server site is behind a firewall, you'll need to allow access to the domain: atlassian.com. You also might need to allow access to other Atlassian domains. Learn about IP addresses and domains that need to be allowlisted

4.b. Choose what to migrate

You can migrate everything together or break it up into phases.

You can choose:

• global page templates and custom system templates, or skip migrating templates

• spaces (their attachments,and the associated Team Calendars), or skip migrating spaces

• attachments only

• all or some of your spaces (and their attachments)

• all or some of your users and groups from the Confluence directory

• all apps that you marked as Needed in Cloud when assessing your apps

Attachments only

You can choose to migrate space attachments before migrating other space data. We recommend that you migrate attachments first for the following reasons:

• If you migrate attachments after migrating space, some attachments may not link correctly on the cloud because the system requires you to have the media on the cloud before your space data. To ensure you don't lose any attachments or media data, we strongly recommend you migrate your attachments as a pre-migration task. When you select Attachments only, you can only migrate attachments related to the selected spaces.

• It reduces the time window for the remaining space data migration. In general, the more attachments you have, the more downtime you can expect. Learn how migrating attachments only reduces downtime

You will then need to migrate the spaces at a later time. This will automatically restore the links between spaces and their attachments. The migration assistant will recognize any attachments that have already been migrated and skip over these. It will still migrate new attachments and also remove the links for any attachments that have been deleted.

Users and groups

You can choose to either migrate all or some of your users.

If you choose to migrate all your users, the first time you do so all your users will be added to your Cloud site. Every migration, after the first, we will just link your data to the users that already exist in Cloud. Learn more about migrating a large userbase

When you migrate your users, they will be added to their groups when they get to Cloud. You'll need to review and approve group permissions after you migrate. When you approve group permissions, your users will be given Confluence access and will be added to your bill.

We won’t send an invitation to your users. To invite your users you can choose to send an invitation from the Administration space after you have migrated, or send a link for them to log in themselves.

Other things to be aware of when migrating users and groups:

• We’ve been rolling out changes to user management that may affect your migration experience. From your organisation at admin.atlassian.com, if the Users list and Groups list are under the Directory tab, you have the improved user management experience. This means that the users and groups across sites will be merged under the organisation.

• Users are migrated using email address as the source of truth. On subsequent migrations, the migration assistant will link users by email address rather than re-migrating them. Learn more about migrating a large number of users 

• You must validate all your user accounts (email addresses) before migrating to cloud. Migrating unknown user accounts can potentially allow unauthorized access to your cloud sites. For example, if you had users in your server instance with emails that you don’t own, say “email@example.com”, you might be inviting someone who owns “@example.com” to your site in Cloud.

• Confluence Cloud is subscription-based and billed on a per-user basis. Learn more about available licensing options 

• If you use an external user management system, we recommend synchronizing it with your local directory before migrating. This is to make sure that your users and groups are up to date before you transfer any data.

• Usres with disabled status in your server site will be migrated as active but without any product access or group membership. This means they will not be counted as active Confluence users for billing purposes.

• If we find a group in your Server site that has the same name as a group in your cloud site, we will merge the users from the server group into the cloud group.

• Global settings and global site permissions are not migrated with this tool. You’ll need to set these manually after migration.

• If you have users that already exist in your destination cloud site and you choose to migrate users with this app, the following will occur:

  • If a user has product access in Cloud, but has disabled status in your Server site, they will continue to have product access in Cloud after migration.

  • If a user does not have product access in Cloud, but is enabled in your Server site, they will be granted product access through the migration process.

Global templates

To add global templates to your migration:

1. In the Global templates section, select one of the following options:

• Migrate global page templates

• Migrate custom system templates

• Migrate all global templates

• None

2. When you’re ready, select Add to migration.

Spaces

If you want to migrate all or some of your spaces choose All from the options. You’ll then be able to select what spaces you want to migrate. If you aren’t migrating any spaces you'll be taken straight to check for errors.

To add spaces to your migration:

1. In the Spaces section, select one of the following options:

2. Select the spaces you want to migrate.

You can filter or search for particular spaces using the space name or key or select any of the following options in the table.

You can sort spaces by any columns shown on the space selection screen. Also, you can filter spaces according to their migration status and the date they were last edited. Here’s a brief description of the features on the space selection screen.

Features on space selection screen	Description
Select and sort spaces based on the migration status	The Migration status filter helps to filter spaces based on their migration status. The space migration statuses can be: NOT IN ANY PLAN: The space hasn’t yet been added to any migration. QUEUED: The space has already been added to a migration waiting to be run. RUNNING: The space is currently migrating. STOPPED: The space was added to a migration, but the migration was stopped at runtime. FAILED: The space migration failed. MIGRATED: The space migration is successful. The Migration status column sorts spaces based on their migration status.
Filter and sort spaces based on when they were last edited	The Last edited filter helps to filter spaces based on when edits were made related to an attachment, a page, or a space description. The edits don’t include views, likes, and comments. The Last edited column allows you to sort the spaces based on the elapsed time since an attachment, a page, or a space description was edited.
Sort spaces based on the Pages column	The Pages column allows you to sort the spaces based on the total number of blogs, drafts, and current and previous versions of pages in the space.
Sort spaces based on the Attachments column	The Attachments column allows you to sort the spaces based on the total size of the space attachments.
Filter and sort spaces based on the Space type column	The Space type filter helps to filter spaces based on the type of space, whether Site or Personal. Site spaces are shared spaces. Personal spaces are private spaces. The Space type column allows you to sort the spaces based on the space type.
Sort spaces based on the Team Calendars column	The Team Calendars column allows you to sort the spaces based on the number of Team Calendars in the space. Team Calendars is available as a feature in Confluence Cloud Premium and Enterprise. Your Team Calendars data is migrated regardless of the type of Confluence plan. But to access this data after migration, upgrade to Premium. Learn more about upgrading to Confluence Cloud Premium

Team Calendar components that are not migrated:

• Internal subscriptions: In Confluence, a Team Calendar is linked to a specific space. Internal subscriptions lets a team view events from a different space's calendar, right inside their own Team Calendar. Internal subscriptions are not migrated. After migration, your Team Calendar will still have all its own events, but won't show the events from other spaces' calendars that you had subscribed to. To get those events back, you'll need to set up the internal subscriptions again in the cloud.

• Jira linked Team Calendar events : Your Team Calendar can include events linked to Jira projects, these events help you visualize key dates from Jira. However, during the migration process, these Jira-linked events are not migrated correctly. The connection between your calendar and Jira changes in the migration process, and there events do not appear in cloud.

3. When you’re ready, select Add to migration.

Apps

You can choose to migrate all the apps that you marked as ‘Needed in cloud’ while assessing your apps. Or, you can choose not to migrate any apps at this stage.

4.c. Check for errors

In this step, the Confluence Cloud Migration Assistant looks for warnings or errors it should display as it runs pre-migration checks on the following groups:

• system

• app version of the Cloud Migration Assistant

• users and groups

• spaces

• apps

  • app vendor checks
    
    

If you select the Continue and fix later button on this screen, you can come back to view the checks after you have saved your migration.

As examples, the Cloud Migration Assistant checks if:

• your Confluence version is up to date

• your cloud token is valid

• your Migration Assistant app is up to date

• users in your migration plan are within the user limit of your cloud plan

• all your email domains are trusted

• users have valid and unique email addresses

• groups will merge through the migration process

• spaces already exist in your Cloud site

• spaces are publicly available and searchable online

• app assessment is complete, or you need to change your app assessment decision

• you need to remove apps from this migration

The table below explains what the symbol next to each listed message means.

Symbol/Message	Description	Action required
	A green tick means that the check has passed.	Proceed to the next step in your migration.
	A yellow warning means that you can continue, but you need to be aware of a potential issue.	Expand the error and warning messages to reveal more details and links.
	A red error means that you need to resolve the error before you can run your migration.	Expand the error and warning messages to reveal more details and links.

Understand the checks

System checks

The Cloud Migration Assistant will highlight if ‘The Migration Assistant is not up to date’. This means that you will need to upgrade to latest supported version of the CMA.

Users and groups checks

All users will need to have a valid and unique email address. If we detect invalid emails or multiple users with the same email, you will get an error. You will need to fix these email addresses before you can run your migration.

If you have chosen to migrate all users, we will check to see if you have any groups with the same name already in your Cloud site. If we find groups with the same name, we will merge the users from the Server group into the Cloud group with the same name. You can continue with your migration without fixing this issue, but it’s important to check that this won’t cause permission escalation.

Space checks

If you’re migrating spaces we'll check to see if there will be any space key conflicts. If you get an error you can:

• delete duplicate spaces from your Cloud or Server sites

• reset your Cloud site

• choose not to migrate these spaces by removing them from your migration

You'll need to resolve any space key conflicts before you can run your migration.

Apps checks

The Cloud Migration Assistant lists errors and warnings when it checks apps for any issues that can potentially impact the migration of your apps.

• Read about pre-migration checks for apps

We also provide App vendor checks, which are checks that app vendors (Marketplace Partners) run on your instance to highlight and provide resolutions steps for issues that may impact the migration of their app’s data to cloud.

• Read about app vendor checks

4.d. Review your migration

This is the final step in setting up your migration.

If everything looks correct and you want to start your migration, click Run now. If you would like to start your migration later or you still have errors to fix, click Save. If you choose to run your migration, it will still be saved to your dashboard. There, you can view the progress and details of all your migrations.

4.e. Manage and run your migrations

Your saved migration will be listed on the migration dashboard, where you can View details, Run, Copy, Edit, Delete, and Archive it. You can also check the status of a migration, monitor the progress, stop a currently running migration, or create a new one. You can create as many migrations as you need.

Status definitions

Migration progress

The View details option on the Migrations dashboard opens the migrations page that shows the status of the overall migration. It also lets you view the progress of:

• Pre-migration checks

• Space data migration

• Attachment migration

• Users and groups migration

• Global template migration

• App migration

Data migration progress

Within this migration page, use the Data migration progress section to monitor:

• the progress of users and groups, global templates, and spaces

• review the statuses as the migration completes

The following table explains the various progress statuses for space migration:

App migration progress

Use the App migration progress section on the screen to:

• monitor the migration progress of each app, and

• review the statuses as the migration completes

The table below explains the various progress statuses for app migration.

Re-run an app migration

You can re-run an unsuccessful app migration for individual apps that display a failed or incomplete status, without having to create a completely new migration plan. This feature allows the Cloud Migration Assistant to retry an app’s migration, and resolve issues that may have previously failed or left the app’s migration to be incomplete.

To re-run an app, select Re-run in the ‘App migration progress’ table.

Re-run limits

• Re-run the app migration within 12 days of when you first started running the original migration. The app re-run feature will not be available for apps after the 12-day time-limit.

• This features is only available for apps that display the failed or incomplete status. It may not be available for certain apps that don’t support this feature.

After migrating

Depending on the type of migration, there may be some things you need to do once your migration is finished.

Users and groups

To make sure your users and groups are set up correctly:

• Review members of groups and approve their permissions by going to Review imported groups. (If you have the Free plan, permissions can’t be modified; users and groups retain the same permissions that they had on your original site.)

• Add users to the generic groups if necessary. The generic groups are: "site-admins", "system-administrators", "atlassian-addons", and "atlassian-addons-admin".

• If you use an external user management system, check that your users have synced correctly.

• When you are ready, invite your users. Go to Administration > Users > Show details and then Resend invite. When they first log in they may be prompted to set a new password and add personal details.

Spaces

After migrating spaces, it may take a while for them to appear in the space directory. However, you can still access them via a direct link.

To check that your spaces have migrated successfully:

• Review content and spaces, or ask your users to review their own content.

• Check for any instances of Former User. This means that we were unable to match content to a user.

• Link your other Atlassian products by going to Settings > Application links.

• Use the Jira macro repair to update any links to Jira. On your Cloud site go to Settings > Jira macro repair and follow the steps.

Additional actions

You can also perform the following additional actions:

• convert pages in the legacy editor to the new editor. Learn how to convert pages

• install any apps you wish to use and onboard your users.

For the full overview of post-migration actions check out the Cloud migration guide. 

More information and support

We’ve a number of channels available to help you with your migration.

• for migration planning information, go to the Atlassian Migration Program website

• for technical issues or support with strategy and best practices, get in touch with our support team

• for peer advice, ask the Atlassian Community

• for expert guidance, work with an Atlassian Partner

Support for Atlassian Server products ends in February, 2024. Learn more about the Server end of support timeline.