Best Practices Cloud Migration Jira and Confluence

Atlassian Cloud migration of Confluence or JIRA environments is not to be underestimated. Over the years, you've accumulated a myriad of pages and sections that you need to move to the cloud. Your teams have established a wide variety of workflows and have probably come up with custom solutions to make their work even easier and more efficient. In addition, you probably have a myriad of apps on your system from the Atlassian Marketplace that support workflows, or provide important data in Jira or Confluence. Read our best practices for migrating to the Atlassian Cloud now.

Our best practices for migrating to the cloud

Migrating a daily used Jira or Confluence system to the cloud can be a real challenge for your IT department and system admins.

Over the past year (2021), we have already been able to migrate several Jira and Confluence systems from Server / Data Center to the Cloud and have come up with the following migration best practices. We have published our best practices in 6 phases subdivided:

Phase 1: Detailed preparation and analysis

Why do you want to move to the cloud and what do you want to achieve?

No migration is like the other. As mentioned above, each system has different individual characteristics and adaptations. This makes it necessary to first determine all relevant facts why a change to the cloud should be carried out. 

We look at the following points in more detail beforehand:

Working out the qualification criteria for migration to the Atlassian Cloud

An important step in our best practices for migrating to the Atlassian Cloud is to identify the qualification criteria for your systems. This will ensure that there are no unpleasant surprises during the project.

For what reason do you want to move to the cloud? 

Here, several reasons can be relevant for your company. We have briefly summarized some of the most common and currently most important ones for you here:

1. Cloud adoption across the enterprise and Atlassian systems like Confluence are a part of it.
2. Is a cost factor the decisive reason? - On Premise or Data Center systems can be very expensive and the administration effort can be high.
3. The IT infrastructure is no longer managed internally and is managed directly by the system provider.
4. Restructure and "Get fit for the future" - The cloud is part of your future strategy.

These four points already give you a clue. The cost factor in particular is relevant or even decisive for many companies. Through the Atlassian Cloud, the administration effort of your IT infrastructure is much easier to manage. This is managed and maintained directly by Atlassian in the cloud. This leaves more time to focus on other important things. In addition, you are only charged for what is actually used, and scaling the environment is flexibly realizable from one day to the next.

Your requirements - for the cloud and for existing instances

The cloud has many advantages, but also some disadvantages and is still a very young system. This means that you can't use all the functions and apps you currently use in the cloud. Here you either have to do without it for the time being, or look around for alternatives.

Besides apps and integrations, there are a handful of other requirements you'll probably need to meet. 

To help you get started, we have summarized the most relevant requirements for Confluence here:

The most common requirements and questions

1. What does your Strategy for migration out?
   1. Directly - All data, integrations, apps and users move to the cloud.
   2. Step by Step (Phased Approach) - Only parts of your existing instances are migrated. For example, project or department based.
   3. Start fresh - Everything new! No data is transferred and the cloud instance is set up again.
2. Continuation of apps, integrations and individual programming. Analyze here which apps are already available in the cloud, for which there are already alternatives and which are no longer available.
   1. Are there must-have apps that need to be in the cloud?
   2. Are all apps also available for the cloud?
   3. Are there any technical limitations to the Atlassian Cloud? 
3. Transfer of existing functions and individual adaptations to the cloud.
4. Number of users required must be available in the cloud.
   1. The enterprise cloud is currently (as of 2021) only available with 20,000 users.
   2. A high number of users leads to longer project duration
5. Compliance, security and data protection regulations must be enforceable.
   1. Can the server location be freely chosen?
   2. Are there any legal requirements that need to be met (DSGVO, GDPR)?
   3. Is the system used globally or only locally? 
6. Migration of existing data
   1. Can the existing Jira or Confluence structure be cleaned up and streamlined beforehand? 
   2. Do all existing data need to be migrated?
7. External systems must be connected to the Atlassian Cloud.
   1. Are integrations already available or do they have to be programmed first? 
   2. Do the providers of these external tools offer interfaces?
8. What is your estimated budget for migration?
   1. A migration is associated with a lot of time. Costs are therefore not only visible in monetary terms.
   2. Can I save money by switching to the Atlassian Cloud? - You can get a first estimate with the Cloud Savings Calculator Catch up
   3. Are external partners needed?

With this Plugin you can clean up your existing Confluence instance first.

Pro Tip: For large or complex server instances, a phased approach is undoubtedly the recommended strategy for migration. Small changes made incrementally allow everyone on your team to gradually get used to the new system without confusion and/or risk.

The answers to these questions will quickly mean a shift in your approach to the migration. Depending on how complex your requirements are, it is advisable to bring in an external Atlassian partner for the migration.

User Management in the Cloud

User management in the Atlassian Cloud works a little differently than on the server or data center. That's why you should get to grips with it early on. 

On server and data center each user needs an access for each system.

On Server or Data Center you can use this function with Atlassian Crowd and thus provide Single Sign On.

In the cloud, on the other hand, it is sufficient to create one account per user to be able to access all systems and log in.

When adding new users, you can also define access permissions. This means, for example, which products (Confluence, Jira, JSM, Bitbucket, etc.) can be used by whom.

Another security precaution you can use in user management is to only allow users to access your systems who have accounts created under your managed domain.

Here you can find more information about efficient User and authorization management. 

Before you move on to Phase 2 of Best Practices, make sure you've considered the following points:

1. Timeline: Depending on the complexity, migration to the cloud can take between 1 - 12 months. 
2. Risk Analysis: Note that on premise and cloud are different in many ways and can impact your business. Here you can find more information about the differences: Cloud vs. Data Center / Server.
3. You've chosen Migration strategy decidedly
4. App Assessment: You've looked into your needed features and apps and checked to see if they're available in the cloud.
5. Open a MOVE ticket, to get support from Atlassian and simplify the migration. (Required only if you are doing the migration without an external partner)

Phase 2: Planning

This phase of our best practices for migrating to the Atlassian Cloud is all about planning through the project and creating all the necessary tickets and tasks that are needed. 

The more detailed you are here, the clearer your migration will be in the end. In addition, you can specify in the roadmap how much time you invest in each phase.

Our migration planning best practices

1. License planning: Discuss with your team what licenses are needed for the cloud. 
2. Project Planning: 
   1. Determine how much time is needed to migrate to the Atlassian Cloud and create a project plan and schedule
   2. Determine and organize your project team. This can consist of an internal team as well as an external Atlassian partner.
   3. Create a cloud test environment. Here you get access for a Confluence test environment and Jira test environment.
3. Sign up for a free cloud migration license and request your cloud site URL for your target instance. For example: companyname.atlassian.net
4. Determine your migration method: Direct, Step-by-Step, Fresh Start
5. Determine the scope of your migration: The assessment phase already gives you a precise overview here. However, it is important to determine exactly how extensive your data to be migrated is and which of it is to be transferred.

Pro Tip: To ensure that your migration to the Atlassian Cloud does not get bogged down, it is important to have a concrete time plan for the individual phases. Of course, these should also be adhered to.

Phase 3: Preparation and testing

In this phase of best practices for migration to the Atlassian Cloud, all the necessary steps are taken to ensure a smooth transition. That is, this is primarily about preparing all the people involved, your data, and the systems.

To make your migration as simple as possible, you should create a process or project plan. This maps the individual steps and phases exactly.

Best Practices Atlassian Cloud Migration - The Preparation

Preparation is half the battle. Therefore, make sure that all relevant factors and requirements for the migration have been considered. In our migrations so far, we have found that analyzing and qualifying the complexity of the existing instances of Jira or Confluence is a major part of the work.

Best practices to prepare for a smooth migration

Communicate your migration strategy and plan with all stakeholders

Together with our customer, we communicate our jointly designed strategy. In concrete terms, this means how the migration will proceed. This ensures uninterrupted use of the actively used systems. And what steps will be taken to make the transition to the cloud as easy as possible for all users after the migration.

Migration of the apps used

Analyze the plugins used and specifically question their use. In some cases, plugin functionalities can be replaced with standard cloud functionalities. The Cloud Migration Assistant helps you with the analysis and shows you the usage of the respective apps. If a plugin is to be replaced, create a plan for the procedure. Pro tip: To search for Confluence plugins and replace them if necessary, the following plugin will help you → Plugin

For apps that are to be migrated, the migration path must now be analyzed for each app. In part, there are fully automated migration paths which are offered by Atlassian via the migration wizard, but it is usually not possible to avoid that a large part of the apps and the associated data must be migrated manually. Here, too, make a detailed plan of how you want to proceed with the apps to be migrated in order to achieve a successful and holistic migration in the end.

Check if your server or data center version is supported

Migration to the cloud is currently not possible with all versions of Jira and Confluence. Therefore, check which version is currently used in your company and whether it is compatible with the cloud. 

Here you can find more information about supported version: for Jira, for Confluence.

So before you can start migrating, you must first upgrade your systems to a supported version.

Clean up your system

According to the motto, what is no longer needed, must go. Of course, you don't have to be quite that drastic. And by "gone" I don't mean in the trash, but archiving, removing duplicates or merging content. 

Best Practices for Migrating to the Atlassian Cloud: Archive and Clean Up

Confluence

• Data from past and completed projects archive. For example, by time period (Older than ...), by project priority, client, budget, etc.
• Confluence projects, sections and pages: A lot of content is often written only once, never paid attention to again, is outdated or duplicated.
  Our Best Practice: Every department and team should review your section and delete or merge redundant content.
• Images, videos and other content: Similar to projects and other data, graphical assets can be archived or deleted.

Jira

• Projects: Data from completed and old projects may no longer be useful. Analyze which of them can be archived.
• Custom Fields: Your teams love custom fields. For pretty much everything. However, they bloat Jira unnecessarily, there are duplicates and Jira becomes confusing. Delete unnecessary ones and merge duplicates.
• Issue Types: Make sure that the number of issue types is manageable and that projects use similar workflow structures. This way you don't have to create or assign too many when migrating.
• Workflows and Schemes: Remove duplicates or merge similar workflows. Often your users create more without first checking if an existing one can be used. 

In our Guide for a maintained Jira system you can find more best practices for managing your Jira system.

Confluence & Jira

User Profiles: In Jira as well as in Confluence, quite a few user profiles accumulate after a few years. Profiles of former employees, external partners, freelancers, etc. Analyze which users are active or regularly work for your company. Delete the rest. This is also important to find out which user tier you need for the cloud.

Before you proceed with the migration, we strongly recommend that you thoroughly review your existing systems. 

Access permissions for anonymous users

You can skip this step if only registered users are allowed to use your systems.

Not all content is only visible to registered users and is made available to the public. These can be functions of a Jira Service Desk or parts of Confluence.

For example, if you and your team use Confluence as a knowledgebase or help center, it will probably be made available to the public. This is where your customers can get all the information they need about specific issues. However, these areas must be set up so that they can also be viewed by non-registered users.

Before migrating to the Atlassian Cloud, review the access permissions for anonymous users and then configure the settings in the cloud.

You can find the configuration here: Settings → Schemes → Permission Schemes. Then click on Permissions for the permission scheme of the project for which you want to enable or disable anonymous access.

User Tier for the Cloud

To ensure that all your users end up on the cloud, you need the right user tier. Here's how we approach our best practices for migrating to the Atlassian Cloud: 

1. Analysis of active users: How many users are currently active? That is, how many employees need access to the system. 
2. Do you regularly work with external partners? If yes, how many?
3. Does your business intend to grow? If so, create a buffer.
4. When in doubt, choose the higher user tier.

Pro Tip: You can calculate your monthly cloud costs here: Jira, Confluence.

Your strategy for migrating your users to the cloud

As already mentioned above, not all users have to migrate to the Atlassian Cloud at the same time. You can proceed step by step (e.g. department- or project-related), or migrate all users at the same time.

Whatever you decide. Communicate your plans with your team and employees. This way, they can get an idea of the new system early on and prepare themselves.

Pro Tip: We present our best practices or in our migration to the users in a presentation and already give first tips. What changes and innovations are there? How does the change work? What happens with the old system? When will the old system be switched off? In addition, we provide a short guide and training materials for the cloud.

For more information on user migration for Jira and Confluence, please see here.

[Add Cloud Migration CTA Here]

Phase 4: Testing the migration to the cloud

At the beginning of this guide, we already showed you how to create a test system of Jira and Confluence. This will be used in this phase. 

Before you go and transfer all your data to a production system, you should test your requirements and the migration of your instance and data. 

This will ensure that all data is transferred and apps in the cloud are working. When using new tools, there are always errors and further questions that you can solve during the test. 

So the test is another safety precaution before you shut down your old systems. 

This way you can run your first test and check the cloud for functionality and integrity.

Atlassian Cloud Migration Assistant: 

This helps you directly with the analysis of your apps. Gives you the possibility to transfer selected areas of Jira or Confluence, migrate users and shows you the status of the migration.

Recommendation:

We recommend that you only use this tool if your Jira or Confluence does not use custom programming or integrations. The tool is especially useful if your systems are "out of the box". In particular, customizations to your servers or data center instances can cause errors in the cloud or not work. These must then be transferred and configured individually.

We use this tool mainly for transferring generic data packages like Confluence areas and pages or for Jira projects.

Pro Tip: Contact us. We analyze your Jira and Confluence Server or Data Center instances and give you an assessment of which migration strategy is best for you. Learn more about Cloud Migration.

This is what you should look for in test migration:

Take your time and analyze the test migration. Check whether all areas/projects were transferred completely. How does the user management look like, were all groups created, were the permissions successfully transferred? Check the content of your pages and issues, especially the content that was created using plugins. Perform test migrations several times to develop a feeling for the process and to gradually eliminate all possible sources of error.

Also test migrate all apps and their content and make sure they work as expected. Once you have eliminated most of the possible sources of error, move into a user-based testing phase and define a responsible person from the business department for each area or project. Show your testers the new testing environment and give them some time to familiarize themselves with it. Get feedback from your testers to help you address any issues before they arise or to fine-tune your migration.

Phase 5: Migration

Was your migration successful? Did you not encounter any critical errors? If so, you can finally start migrating your server or data center to the cloud.

In order for your team to be able to use the cloud as they are used to from the server or data center, you need to do a few things before go-live.

1. Lead the Production migration through: That is, use the Atlassian Cloud Migration Wizard for Jira and Confluence.
2. Redirect users to the new cloud site: Put redirects here. For example, server.jira → cloud.jira.
3. Read Only for your servers or data center instances: This ensures that no further content is created on the old systems during and after the migration. These will then no longer be transferred to the cloud.
4. quality assurance test of the migrated data: Check here if the migration was successful and the migration transferred all the data. In addition, you should make sure that in case of an incorrect transfer, a post-mortem is performed. This way you can quickly find out the reasons and errors.
5. Install or migrate apps: Once the wizard has transferred all the data, it is now time to install and configure all the apps used and available.
6. Integrations of other apps and software: Many apps offer direct integrations with the Atlassian Cloud. Make sure they are installed and configured.

More best practices for migrating to the Atlassian Cloud:

1. Communicate potential downtime, outages, and usage restrictions of your systems on migration day. "Read-Only" should therefore be communicated in good time.
2. Inform your users about the new system and that a change is imminent.
3. If the migration does not take place without errors as expected: Communicate the delay in a timely manner with all internal stakeholders.
   

Pro Tip: Create some internal communication templates for schedule changes, success stories or status updates during the planning phase. This will make it easier for you to keep your team up to date.

Phase 6: Commissioning & Post-Migration

You've done the hardest part. The migration was successful. In the final phase, it is still a matter of releasing all users to the new system, clarifying open questions and conducting a retrospective. 

For you, this means finding out what worked well, where there are problems, and where you still need to work in your Atlassian Cloud.

Pro Tip: Make sure that your users feel comfortable in the cloud, understand the system and, above all, can use it. You can achieve this primarily with training materials and guides. 

So that you also know where the shoe still pinches, you create a service management project to give the users the opportunity to centrally set occurring problems. Tell your users that they can contact you at any time if there are problems. 

What you must not forget: Tell your users that the old systems will be shut down in a timely manner. 

If you'd like to learn more about planning your migration from Atlassian Server to Cloud, or learn more best practices for migrating to the Atlassian Cloud get in touch!