Page tree

RU



If you’ve decided that it’s time for you to migrate to Cloud you might have already started wondering what is the process for migration.

So here we are to tell you that the process consists of 6 phases. Surprisingly but analysis and planning are those things that take almost all the time, not the migration itself.


Phase 1. Assess

First of all, it’s crucial to learn the difference between Cloud and Server if you want to avoid surprises or a mess in the future.

There are different costs, management, security, features, and so on. You can check the details here - https://support.atlassian.com/migration/docs/compare-atlassian-cloud-and-server/

Also, you need to find out what makes your system unique and suitable for you. Explore your system and analyze what products you have and which versions they are , how many people use each of them, what apps and integrations you have, and why.

Accurate auditing and answering questions like “why your system looks the way it looks?” and “why do you need every element of your system?” will make the next phases easier for you.

If you have resources build a team that will work only on the migration process because this phase is only a beginning. 


Phase 2. Plan

It’s time to start planning the migration.

Firstly, using your cloud migration trial, you need to set up your organization and verify your domain. That’s all work for your cloud site for now.

The main goal is dealing with the audit results.

When you have all the gathered information about your system it’s time to cut out unnecessary things. To decrease the complexity, you need to look for everything unimportant you can handle without.

Check these factors:

  • Size: do you need the whole your data and number of users;
  • Apps: check whether your apps available on Cloud and what is the migration process for them;
  • Customization;
  • Number of products: the more you have the more complex migration will be;
  • Hosting: whether you choose consolidation, federation, or hybrid hosting, it can increase the complexity;
  • User management: are you intend to use Atlassian Access.

When you have an understanding of the complexity and you know when you want to have the migration completed, it's time to choose the migration strategy and method.

There are four strategies:

  1. Optimize and shift
  2. Lift and shift
  3. Phased
  4. Start fresh

The first two are for systems with lower complexity (fewer than 5000 users and 10 apps), phased strategy is suitable for higher complexity. The strategy name Start fresh speaks for itself – it’s fast, but you need to forget about your old data.

Detailed information about migration methods you can find here -  https://support.atlassian.com/migration/docs/compare-cloud-migration-methods/

The result for this phase is a migration plan with deadlines and actions.


Phase 3. Prep

This is the time when every single detail about migration should be discussed and explained to your team. Also, you have to choose when and how you want to inform all people that will be impacted by these changes. 

Besides, it’s the time for the last check for your system.

Ensure that your product versions are supported by the migration method you have chosen before.

Clean up your data. Delete all unnecessary data, inactive users, and apps – everything that could affect migration complexity and you can work without. 

Review the pre-migration checklist to be sure you are ready for the test migration:

Jira pre-migration checklist - https://support.atlassian.com/migration/docs/jira-pre-migration-checklist/

Confluence pre-migration checklist - https://support.atlassian.com/migration/docs/confluence-pre-migration-checklist/


Do not forget to install those cloud apps you want to test as well.


Phase 4.Test

We do not recommend skipping this phase. Testing takes time but it will save your mind in peace when it comes to the actual migration.

Do a test run using this testing guide - https://support.atlassian.com/migration/docs/test-your-server-to-cloud-migration/

Back up your data and conduct User Acceptance Testing (UAT).

When you are sure that everything is in order, every issue is solved and you are satisfied with the test results you can start choosing your production migration window.

As you had run the test migration you've known how much time your migration takes, so you can choose the date for your migration. Night time or weekends are better to choose – the time when no one is using your server instance or cloud site.

Also, it necessary to inform Atlassian about your migration window two weeks in advance so they can offer you extra support.

Before your migration, you need to take care of users’ tuition. Prepare user guides for your end-users and admins. Make sure that everybody understands that everything will be different after the migration: URLs, the way a user log in, interface.

You may have the sense of users’ questions after UAT. Use them as a base for user manuals and tutorials.

Make sure your team knows when the migration will happen, what the new workflow routine is, who they contact if they run into an issue.


Phase 5. Migration

Set your server to read-only mode to avoid any confusion for your users.

Follow the steps in the runbook you made during the test migration. 

Migrate all apps you have defined critical.

Check that your data migrated fully and correctly, and that everything is working and in order.

Notify your users about the new URLs and, if possible, apply a site-wide banner to redirect end-users who use the old URLs.


Phase 6. Launch

Congratulations, you have made it!

Now it’s time to share the good news with your stakeholders and give them the link to your new cloud site.

Review the getting started in cloud documentation https://support.atlassian.com/migration/docs/get-your-users-started-in-cloud-after-migrating/ to mark key points and inform your users.

Also, don’t forget to follow the updates on Cloud Roadmap - https://www.atlassian.com/roadmap/cloud.


If you have any concerns about migration, you’re out of human resources or you need help – contact us to get our consultation.

We will help you with every phase and migrate you to Cloud - https://www.teamlead.ru/display/EN/Contact+Us

It’s not a secret to anyone that in 2024 Atlassian Server products will be discontinued.


Due to this situation, there are two types of users. Those who are thrilled to try the migration to Cloud and want to do it now, and those who are not so enthusiastic about it. Some of them are enjoying Server edition so much they are scared to even think about migration and try to put it off as long as they can.


So, is it the right time to migrate to Cloud?


Well, Atlassian does its best to make the migration process smooth and easy. But Cloud still doesn’t have the same functionality we got used to. This is true for Jira and Confluence, moreover the apps as well.
But Cloud has been developing really fast. You can follow up the updates by Cloud roadmap. Atlassian and the app vendors make changes every day and prepare detailed guides.
We are working on our apps as well so you won’t have any issues when the time for you to migrate comes.


But when is the right time?
If you have been using Server for a long time and happy with it, we recommend you to take your time. There’s plenty of time for you to plan, prepare everything, and migrate without any haste.
But if you are at the beginning of system settings we suggest you start looking into Cloud for many reasons:
• You can set the system right on Cloud and forget about migration difficulties.
• You can use the benefit of the Cloud loyalty discount program for enterprise companies. The earlier you migrate the bigger the benefit.
• Free, extended migration trials are another benefit. They last longer than a standard trial and help you to migrate to Cloud over time. You can check the details here.

But the most important question is not WHEN but HOW.


Migration is a difficult process and it needs a detailed plan. You may have many questions in your mind as:
What to begin with? What is important and what is not? Which Cloud plan is the best for our company? Maybe a better option is to migrate to Data Center?
If you’re struggling with these or other questions, write to Teamlead. We will answer all of your questions and lead you through this vital change - https://www.teamlead.ru/display/EN/Contact+Us

Many Jira users, especially those whose work is connected to Service Desk, have the same problem – a huge amount of duplicate issues. It’s a common thing when a client always has the same issue all over again as an unstable connection for example. And it causes a number of issues with the same parameters.

So, is it possible to follow all these duplicate issues?

You may know that Jira has an excellent tool as Automation. It lets you automate your everyday actions and workflows by creating rules to handle required scenarios.

In Automation Cloud Library there is the Close duplicate issues rule, but if you look inside the rule you’ll see that the rule just closes an issue that is linked as Duplicate. It does not show the process of duplicate issues search.

Let’s think about how we can find the duplicate issues using Jira tools.

We can use a JQL query and set the parameters we need to find duplicates like in the example:

The problem is we don’t know the parameters we need because the new duplicate issue does not exist yet.

It can be handled with smart values (you can read about them here - https://support.atlassian.com/jira-software-cloud/docs/what-are-smart-values/. ).

The smart values help us with Automation settings when we want to find duplicate issues using JQL. We can find matches in fields among issues even without knowing the values.


Set up example

Let’s take the case when we need to check for duplicates every new issue with the full match by Problem and Client fields (a client has a repetitive issue).

In case of duplicating, Jira links all the discovered issues to the new one with the link type Duplicate.

It’s easier to search by fields with values to be selected from a list. In this case, we can avoid not accurate spelling problem.


Pick trigger

Determine when the rule starts. In our example, the trigger is a new issue creating. 


Narrow the scope of your rule

New component → Branch rule/related issues

Here we determine conditions for launching a rule.

In our case, we use the JQL with the smart values for the search.

When we set the values for the fields we use this syntaxis:

{{triggerissue.customfield_10034}}

That can be read as "the value of the field with id 10034 from an issue that was the trigger for this rule".

Pay attention that the syntaxis depends on the field type. Here we use the text field syntaxis.

If you have another field type, please, verify the syntaxis by this link - https://support.atlassian.com/jira-software-cloud/docs/what-are-smart-values/

The search through all issues takes time.

To cut the time you can narrow the scope even more. In our case, we check the matches only for issues that were created within the last 3 days.


Ad action

New Action → Link issues

In the example we want the discovered duplicate issues to be automatically linked to the new ones.

We use Link issues action and when we choose the link type we have in mind that this action is for “old” issues so those discovered issues should be marked as is duplicated by.

It was one of the ways how to make your workflow easier using Jira Automation.


Архив

Пока в архиве ничего нет