Documents to help you prepare to migrate your Atlassian server products.
Articles to help assess your migration costs license status.
Learn about migration timelines, roadmaps, app and Atlassian Access with these resources.
Look up resources on Jira and Confluence cloud, data hosting regions, LDAP, and ADFS.
Pre-migration checklists for Jira, Confluence, and Bitbucket.
A collection of topics that help prepare you to migrate your apps to the cloud.
Native tools and resources that will help with your migration.
Documents to help you use Jira Site Import to migrate to cloud.
Documents that walk you through using the Confluence Cloud Migration Assistant to migrate to cloud.
Resources to help get started and testing after you migrate.
Documents that walk you through using the Bitbucket Cloud Migration Assistant to migrate to cloud.
Everything you need to know about moving your data from one cloud site to another.
In general, the more data and users you have, the more downtime you can expect when migrating from server to cloud. We can't provide an exact estimation of downtime because it depends on your internet speed, what data you're migrating, and other variables.
We recommend running a test migration to work out how long to expect your migration to take, document the specific processes you’ll need to follow in a runbook, and review to make sure your production downtime is minimal. Remember to factor in any additional time for things like installing or migrating apps, setting up users, QA testing your data, and anything else you’ll need to factor into your migration runbook.
We’ve put together this guide that walks you through some of the key strategies to reduce downtime and complete migration within your desired timeframe.
Clean up your server instance
The more data you migrate, the longer and more complex your migration is likely to be and could affect cloud performance later on. Use your migration as an opportunity to clean up your server instance before running your test migration.
To ensure successful migration of your server data, use cleanup tools such as the Database Integrity Checker (native to Jira Server) and Instance health (available for Confluence and Jira). Learn how to clean up your server instance
Review your Jira data
It’s good practice to archive inactive or completed projects so they don’t clutter your Jira instance. Learn how to archive projects
Review your Confluence data
Consider removing or leaving behind anything that is not being used. This could include specific pages, entire spaces, attachments, macros, or apps. Learn how to gather usage statistics from Confluence
Set your server to read-only
Depending on the migration strategy you choose, your users may no longer need access to your self-hosted instance. If your users add data to migrating pages, spaces, or issues, this data will need to be re-migrated. You will have to do manual cleanup work that increases downtime.
Put your site into read-only mode prior to migrating to prevent your users from making changes during migration. For Confluence Server, work through each space and remove all permissions for anything other than read. There is no explicit "read-only" mode in Jira Server, but you can do it manually by creating a permission scheme that only allows "browse" permission and applying it to all projects.
Update your site-wide banners for Jira and Confluence stating that your site is now read-only during the migration. If you have users continuing to work in server after the migration, be sure to remove this setting after your migration is complete.
If you have a large userbase, we recommend migrating all your users and groups without any spaces or projects first. This can happen while your users are still working in server, as no space or project data will be extracted (meaning no downtime). Then, when you come to migrate spaces or projects later, it will be a faster migration with shorter downtime. Learn more about migrating a large userbase
Migrating attachments is typically the longest part of migration. With the Confluence Cloud Migration Assistant, when you choose what to migrate, you can select attachments only. Breaking your attachment and space data migration into different stages has the following benefits:
you can migrate attachments weeks or months ahead of space migration. This is a low-risk process and significantly reduces the time window for the remaining space data migration.
when you migrate all space data in a later migration, the migration assistant will recognize any attachments that have already been migrated and skip over these. This saves you a significant amount of migration downtime. The migration assistant will still migrate new attachments, and also remove the links for any attachments that have been deleted.
We’re working on functionality for the Jira Cloud Migration assistant to migrate attachments only for selected projects. Currently, this feature is available via Atlassian Support.
Jira Cloud Migration Assistant
Confluence Cloud Migration Assistant
Get your users started in cloud
Allowing your users to easily transition to their spaces, pages, and issues in cloud is critical to any migration. Make sure you’ve understood and prepared for all the major changes such as how users will log in, new URLs, changes to apps, and UI differences.
Depending on your migration strategy, you can apply a site-wide banner in Jira or Confluence to help redirect end users who are still attempting to access your self-hosted instance. Link out to the new cloud site URL so they know where to go. Learn how to get your users started in cloud
To successfully transition your team, think about creating a clear process for collecting feedback and answering questions about the move to cloud such as office hours or a chat room.
Was this helpful?