How to make a successful migration to the Cloud

Have you been thinking about migrating your Server instance to the Cloud and don’t know where to start?

Have you already done a migration and it didn’t go as well as you’d hoped?

Have you tried reading all of Atlassian’s documentation on the subject and not been able to find what you were looking for?

Keep reading this article, because we promise that now you will finally find out everything you need to know about migrating to the Atlassian Cloud. And you’ll want to read it soon, because 2023 is your year. If you haven’t already done so, it’s time to migrate your Server instance to the Cloud, remember that support will end in February 2024.

Let’s try to summarise the step-by-step process for your migration, taking into account the main tips you need to be aware of every step of the way.

Phases of a Cloud migration

It is important to understand that a migration is a process in itself, you have to go through several phases and stages. Within each phase there are a series of steps that we will have to perform, some are sequential, but others can be done in parallel.

Phase 1: Assess

Perform this phase 3 to 6 months prior to migration

The first point of this process is to understand the current landscape, where it is going and where we are.

Analyse all the features of your instance and compare the differences between Server and Cloud. Not only at the configuration and application level, but also at the user permissions level. Check what is going on in the Server instance: which users actually use the products or applications, whether it makes sense to keep it that way if there are other instances that were not documented, for example.

You will have to spend a lot of time analysing custom applications and integrations. First to determine if they are really necessary in the new Cloud environment, but then to analyse if they are viable in the new environment while keeping the same features or if you need to change applications, or do the integrations in a different way. It’s good that, at this point, you assume that during the process you will have to make some sacrifices: not everything works the same in the Cloud environment.

Decide on the most appropriate subscription plan for the instance: the subscription and licensing approach in the Cloud is different, so you will have to analyse for each product which is the most appropriate version, taking into account the differences in functionality and price in each case. Atlassian offers all Server users an extended free trial to test Cloud features for as long as necessary. That way you can make the migration with more leeway, having months free in the Cloud.

TIP 1

If at this point you have been able to work out the scale of your migration, you may need some help. That’s where you can call us. As an Atlassian partner we will help you with this process. When you do this you are often able to anticipate what might happen and the risks are minimised exponentially.

Phase 2: Plan

Perform this phase 2 to 3 months before the migration

If in step 1 you have already decided that the migration will indeed take place, then the planning begins: what steps we will have to follow to achieve the objective and what will be the best strategy.

After the previous analysis performed in step 1, perform a second analysis to validate whether it is indeed necessary to migrate all the data and what final volume will be left in the instance. This will be vital in drawing up the most appropriate plan. The most important points are the complexity of the configuration (many custom workflows, for example) and the amount of data you have and the space it takes up.

At this point it will be of vital importance to assess the chosen approach to user management. Cloud is completely different from the Server environment. Not only configuring your organisation, to be able to implement SAML SSO policies, but also to verify your company’s domains and claim user accounts. If you also want to synchronise your Active Directory, set policies for users, and ultimately have unified management of all accounts, then you’ll need to consider Atlassian Access as well.

Decide on the most appropriate migration method

This will depend on the overall migration strategy: migrate only active data, migrate 100% of the data, migrate only some projects or spaces or migrate 100%, migrate to a new Test instance, migrate only a group of users…

And finally, prepare a plan as detailed as possible:

• What activities need to be carried out.
• In what order.
• Who will carry them out.
• For how long.
• What dependencies exist between them.

This will make it easier for you to know exactly where you are during the whole process and the possible risks and deviations. Note that to make the migration as smooth as possible, you have the Atlassian migration assistant at your disposal, but you can only use it if the products are in a sufficiently updated version. This is also the time to evaluate this point so that you don’t get a surprise when the project is more advanced.

TIP 1

This migration assistant does not cover 100% of the scenarios and you have to use it very carefully, following each and every step in order and without skipping a comma. This is the only way to get the process right.

If you have come this far, you will have noticed that this process requires teamwork. Not only from the administrators of the instance, but also from the users of the organisation. It is important that you create a team of users who can spread the message, train the users, accompany them during the process… everyone must feel part of it to ensure success.

Phase 3: Prepare

Carry out this phase 1 to 2 months before the migration

Start communicating the migration plan with team members, stakeholders and users. No one should be caught by surprise, everyone should be aware of the timelines that will be followed and in what order.

Prepare the Server instance to be as clean as possible, there are always a few more corners to scratch: clean up as much as possible before the migration (minimise customisations, identify inactive projects or unused schemas).

TIP 1

Pay special attention to the number of users on your instance. Check that the Cloud instance has space for all the users you want to import, to avoid failures during the import. Ideally, work with a monthly subscription during the whole process, and switch to an annual subscription only when the process is finished.

Phase 4: Test

Perform this phase 2 to 4 weeks before migration

This phase is probably more important than the migration itself. It ensures that the plan we have laid out works, but it also allows us to make any adjustments or reconfigurations before the final migration takes place.

If you haven’t already done so, it’s time to back up all your data. Make sure all your information is safe and secure before making a major change like the one you are about to make.

Run a test migration to familiarise yourself with the process, understand the migration assistant correctly, clarify any points if they are unclear…

Remember that the applications will not be migrated natively, so it is a good time to install them in the Cloud instance, verify that their functionality is as expected and calculate the time needed to reconfigure them or make the necessary adjustments in each case.

If it is possible for some users to test on the instance, even better. They are the people who know the most about their workflow, the fields they use… in case of an error, they will be the first to detect it. In addition, they will be the first users to get to know the new instance and assimilate the changes it implies.

If all the tests have worked correctly, then you can decide on the migration window: how long it will take and how many hours it will take to migrate all the data. You will probably have to do it outside of service hours so that users are not affected: at night, on a weekend or at a time when the team does not need to access the instance.

TIP 1

When you run the test migration, you will have discovered that there is actually a double check of data: one check at the time the migration is created and a second check at the time it is run. Atlassian wants to make sure that everything is done correctly and we don’t miss anything in the process. In fact, they make sure that the data, the environment and the process itself will not fail at any point.

This in itself is an advantage, but you have to understand that if you create the migration at the moment you are going to migrate, you are going to make 2 consecutive verifications, which can take several hours just to verify data.

Our advice is that, when you are going to perform a migration, do not wait until the agreed date to create the migration itself. Do it before, verify the migration, and leave only the second verification for the agreed day when you run it.

In summary, save time!

TIP 2

Our recommendation is that you make a first initial migration only with the users, thus preserving all the information of their groups, taking also the customers or clients of the portal to this new environment, so that when migrating the projects all the users exist in Jira and we can avoid possible errors. During the migration process, when the tickets are created, they will be assigned to the corresponding users, but it may happen that, if the users have not yet been created, some issues give an error and have not been created.

TIP 3

A correct communication with the users during the whole process will be vital: not only of the key moments, but also of the implemented changes, of the trainings that will be carried out, of the windows for the resolution of doubts or of the users to go to if something is not clear. The team of users created at the beginning of the project will be a key element.

Phase 5: Migrate

Carry out this phase on the day or days that the migration lasts.

The day has arrived to execute the migration in the definitive Production environment. No fear, you have tried everything possible before reaching this point, the plan is clear, the activities to be carried out are clear and the users have been warned, the time has come.

Execute all the steps as planned, this is not the time to improvise.

Install or migrate third-party applications that are also part of your instance.

Verify that all data has been migrated as expected and that everything is working properly.

TIP 1

Configure the Server instance so that users can no longer create tasks or new pages. Confluence can be set to read-only and Jira permissions can be changed so that projects only allow access but not the creation of tickets or editing of existing ones. This will on the one hand make it easier for users to stop using this instance by mistake, and on the other hand prevent new items from being created in it.

TIP 2

To continue with the fluid communication policy, it might be interesting to communicate a banner in the Server instance to warn users of the new Cloud environment where you are working.

Phase 6: Launch

Perform this phase from 1 to 4 weeks after the migration

Now that it’s over, don’t forget the communication you’ve done up to this point: let everyone know that you’ve migrated, ask what they need to know, document FAQs… all the information that might be important for users, the most requested links or small tips for interacting with the new instance.

Prepare the team of administrators so that during the first weeks after the migration they can identify and analyse possible problems or comments from the users.

TIP 1

Keep up to date with what’s new in the Cloud. In this environment there are continuous changes and new features that you will have to review, analyse and see how they may impact on the current configuration of the instance.

TIP 2

And finally: don’t forget to celebrate success!

And if you need help with your migration, contact us.