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.

A large majority of companies have CRM and Jira tools separately. That situation may hurt sales or even be a cause of losing clients because of unclear tasks or bad coordination.


I this article we won't suggest you integrate your CRM into Jira, but if you wish we also have a special app for that too (we will tell you more about this way in the future). Today we want to give you an alternative way to solve the issue – to keep your clients and products database right in your Jira using our new app Catalog for Jira Cloud.


Catalog can be considerate as a database in Jira. You can keep any type of information you need for your work and then connect it with issues.
You can find more information about Catalog by the link


Create directories for customers, salespeople, and products in Catalog and link them with issues.
And this is only a part of what Catalog can do.
We prepared some use cases to show how Catalog can help your sales processes.

Use case #1

The success depends on many factors such as good analytics and flexibility.
Sometimes you may want to check on your sales strategy. In this case, you’re looking for the list of sales with particular clients to learn which offers were the most winning. The quickest and easiest way to do it is to make a report.


Use a filter to see the offer for all the sales that were won:
Client – Client’s name
Status - win
Period – from 01/09/2020


Also, you may want to check the offers that were not so good:
Client – Client’s name
Status - refuse
Period – from 01/09/2020


To see the full picture, you can expand the field of your analysis by checking out, for example, if there any correlation between national holidays and the possible success of a deal with particular clients. You can check any idea that comes up to your head fast and easy.

Use case #2

It’s a huge mistake to forget about a client.
Using Catalog for Jira Cloud you can track within 30 seconds whether all your clients have their own agent. Just sort your clients by agent and those who didn't have one would be on the top.

Use case #3

Check if your sales team achieves the leads plan for this month:
Directory – Clients
Department - Sales
Period – from 01/09/2020

Use case #4

Another key point to success in sales is people. If you have good management in sales team you have the top sales. We highly recommend you to have a directory in Catalog with the list of your sales people that includes their KPI, qualification, and skills. It may help you when it's time to give feedback to your agents. 
Those of them who are lack of sales skills and knowledge should be trained and motivated to improve. The top sales agents should be praised and respected.
You can do both by calling a meeting where the top agents could share their experience and knowledge with those who were lack of competence so they could learn.
Sort all of your agents by KPI and filter by period. To find those agents who are not good at sales use reverse sorting.


Check how Catalog for Jira Cloud may increase your sales department effectiveness using the trial version by the link
If you have any questions or you are not sure if Catalog to be effective in your business case, we are happy to consult. Please contact us via our HelpDesk Portal.

For those of you who are interested in integrating a CRM into Jira.


JQL (Jira query language) – is a powerful query language in Jira that helps to improve searching for necessarily issues and affects work efficiency.

You just write the values you need and get those issues that match them as a result. If you often use the same values for searching you can save it as a filter.

And if your queries are accurate and precise you can make filters that will be the basis for creating agile boards, gadgets, and reports.

The way you write a query can influence the speed and quality of your work.

We prepared some hints that help you to create queries «like a pro».


Operators OR and IN

It’s a common case when a user needs to find issues that have one of selected values from a list in their field.

It can be done like this: product = cookie OR product = milk OR product = jam OR product = butter, but there is a big chance to make an error or to forget something because the query is too long.

The opposite operator IN makes the query quite short. You just need to separate the values with commas: product IN (cookie, milk, jam, butter).


Functions

It happens quite often when users create unnecessary “individual” filters.

For example, John wants to create a filter that shows issues assigned to him. So, he writes the query assignee = John and save it as “My issues” filter. At the same time, there is already assignee = Olga filter created by Olga.

It’s not a big deal but the more filters created the harder maintaining them.

It’s better to create just one filter like assignee = currentUser(). In this case, any user sees issues assigned to them.

Another example: a user wants to see a list of issues for the current version of a product. The query fixVersion = 1.3.0 will be out of date as soon as the work under version 1.3.0 is finished. But the query fixVersion in unreleasedVersions() always gives you the list of issues that has an unreleased version of a product.

This abstract way of writing a query without strong values is called JQL functions.

There are some examples JQL functions that can be used for:

  • Searching for issues that were created during the last X;
  • Searching for all the issues that are at the same projects and leads by a specific user;
  • Searching for issues that were created by users from a selected group;

There is a list of functions in Jira that can be used for searching for information which is true for the particular present moment.

The full list of functions you can find there:


Project Categories

One of the underrated methods of searching but still a good one is using parameter Category. Instead of making JQL queries as: 

project = Alfa OR project = Beta OR project = Gamma

 or  

project in (Alfa, Beta, Gamma)

you can set a category for a project and use it for filtering.

For example, we have five projects. Three of them have the category “Development”, one of them – “Sales”, and the last one – “HR”. If we want to see issues for “Development” category, we write this JQL-query:

projectCategory =Development 

It’s more convenient when the number of projects is growing. There is no need in editing filters with every new project.


A few words about filter editing.

Jira administrators have to remember every filter. If an object is changed or deleted the filter using the object or object’s field option becomes useless or crashes.

And it’s difficult to find all of those damaged filters by yourself. The only thing you can do is waiting for users to complain about some non-working gadgets or some reports that show false data.

Another way of managing filters is using the app Subscriptions for Jira - Filter Manager.  You can find all the filters that are damaged or contain a specific part of a JQL query with it.

Administrators can operate with any filters but users can manage the filters created by them.


Using JQL queries and functions definitely can make any work process easier, so we recommend Jira administrators to teach users at least the queries and functions we mentioned in this article.

The more correct queries the less useless work for everybody.

HR can-do

Before the Holidays we told you about our new app Catalog for Jira Cloud that takes care of storing structured data inside Atlassian Jira in the most convenient and cheap way. 

In a few words, the Catalog is kind of a database right in your Jira. You can keep in Catalog any information you need for your work and moreover link it with issues.

You can find out all about the potential of Catalog for Jira on the Atlassian Marketplace.

So, let’s take a look at use cases to get to know how Catalog can make HR’s life easier.

1st use case. Find me a person with the right skills.

There is a new project in your company, and you need to find Python senior developer from IT department who speaks German, that suits to lead the project.

There is nothing easier!

Use a handy filter and set:

  • Department – IT
  • Language – German
  • Skill – Python
  • Position - Senior

If there is more than one person you can invite all of them for an interview or just flip a coin.


2d use case.  Quick report.

At the end of a year, you have to prepare a presentation that shows who has made the company stronger in Development department that year.

Just find the real people and their strengths.

Using the same handy filter set:

  • Department – Development
  • Hire date – Is after or equal to 01/01/2020

After that, you get the list of newcomers who joined the company that year. You can check out columns like skills or languages looking for the information that presents their personalities. Also, it might be great if you used photos.


3d use case. Document monitoring.

You need to create some issues to prepare all the necessary documents for those employees, whose contracts expire within two months.

It can be done in two steps.

First using the handy filter find all the employees by setting: Contract expires – within 2 months.

After that when creating the issues specify the employees from Catalog.

And arrange the issues.


If you have some specific use cases and you’re interested in whether Catalog can help you with them, please contact us at https://jira.teamlead.ru/.


You can always try Catalog for Jira Cloud before buying using the trial period. That is absolutely free -  https://marketplace.atlassian.com/apps/1222271/catalog-for-jira-versatile-directories?hosting=datacenter&tab=overview

Do you have nightmares that your boss wants you to integrate a coffee machine into Jira?

Are you tired of integrating with Jira literally any software your company uses, like EXCEL, CRM, HRM, Moviemaker, etc.?

Or maybe do you have to store data as issues? So, you spend hours creating issues for hundreds of items, sales, people and other things instead of doing your work.


But we say NO to waste of time (and your energy)!

We have a solution for some of your problems.


Our team Teamlead was tired of making issues for everything: assets, CRM data, employee cards, and so on. Instead of creating an issue over an issue, we have created a new app Catalog for Jira Cloud that is much better at storing data.

The idea of Catalog is keeping all structured data you need for your workflow right in your Jira.

It’s a perfect way to storage all the information your company needs, especially if it’s not big data. Comparing with integrating a real Data Base with Jira, using a catalog is easier and, what is more important, much cheaper. You don’t have to pay for an extra license and struggle to try to integrate an external database through a connector, even a good one, such as Elements Connect for Jira.

The reasons why Catalog for Jira Cloud is useful for you:

  • There can be as many directories as you need, and it’s your call what to be the objects. Make employee cards, customer cards, product cards, equipment cards – any cards you want. Every department gets its own directory.
  • We created a simple handy filter, so you don’t have to worry about teaching sql-queries to all users.
  • Managing the data is the users’ job now. You just need to create some structured templates to make collecting the information easy and convenient.


To be honest it’s not 100% true that we created Catalog just to make administrators’ life easier.

Our first priority was users – the people who will use our app.  

And special for them we took care of these things:

  • The Catalog is a database into Jira so now you can get the information you need just in one click. The Catalog is located on the upper panel of Jira.
  • Information about an object can be linked to an issue. For example, you can link the stores, where particular equipment can be bought. And this issue will be automatically linked to that object.
  • The abilities of our filter are great. You can find all the employees, whose names are Jack, and works in the Sales department, and made ten sales in November, and were born in May at the same time! Or make some useful reports.
  • Working with Catalog is simple. Understanding how to manage information with Catalog is easy for any user from any department. You don’t have to get specific knowledge to work with it.


The Catalog is a fast-developing app. In our future updates, we are planning to make reports even better and expand the abilities of connection between issues and objects.

Revalue using Jira for your business processes by letting Catalog care about your data.

Try our app Catalog for Jira Cloud and tell us: What do you like? What did we miss?

Please, leave your comments and suggestions. Let us know if you have any questions and use cases – we are happy to help.

You can download the trial version of Catalog for Jira Cloud here - https://marketplace.atlassian.com/apps/1222271/catalog-for-jira-versatile-directories?hosting=datacenter&tab=overview



We’ve released new versions of our main apps for Atlassian products - CRM, Calendar, HelpDesk for Jira compatible with Atlassian Data Center and added high-priority support for customers who upgrade to Data Center (DC).

It is an open secret that  IT is a crucial asset for any company. We know that customers have to be sure in apps they use. And Data Center is a solution which can give this sureness. That is why we have released new versions of our apps - CRM, Calendar, HelpDesk for Jira and others compatible with Data Center. 

But we also realize that Data Center license is only a brick in the wall of sureness and we provide high-priority support for all our customers who upgrade to DC. High-priority support includes SLA with 2 hours response time in business hours (MSK) and dedicated manager to guideline through migration process.


Teamlead apps Data Center ready:

Calendar for Jira - Plan Team Activities

CRM for Jira - Customers & Sales 

HelpDesk for Jira - Customer Portal &SLA

Subscriptions for Jira - Filter Manager

Werewolf for Jira - Switch to User (SU)

Werewolf for Confluence - Switch to User (SU)

Reminder for Jira - Follow Up Issues

Agile Filters


For any questions  - support@teamlead.ru