Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Migration planning

Nicolas Mourier
Contributor
February 25, 2022

Hello,

I posted before about the migration I'm in charge of from JIRA Server to Cloud but would like more clarification/help.

I have read this:

  • Data won’t be overwritten or deleted

  • Data may get linked to avoid duplication

  • Using Site Import and the Jira Cloud Migration Assistant can cause data duplication

 

So If I understand correctly after the migration is done both JIRA Server and Cloud will be running with the data. Therefore I'll be able to tell the team to switch to JIRA Cloud, am I correct?

If yes, a good way to do the migration would be to plan the migration during a weekend; communicate about it and have

We use Confluence with links to tickets (stories, epics, ...) will they still work after the migration?

3 comments

Comment

Log in or Sign up to comment
Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 25, 2022

It depends on a few factors.  Depending on how many users you have, you have two possible import options: Site Import and JCMA. If you use Site Import, all contents in Jira Cloud will be deleted and replaced with your imported data.  If you use JCMA, you will migrate Project by Project and go in to empty Projects in Cloud, thus preserving everything else.

My advice is to plan a change control.  Test everything before your change control weekend, and migrate in a controlled manner.  

  1. Get your users and groups in Cloud first
  2. Set up Atlassian Access (if desired.)
  3. When you start your change control, make Jira Server unavailable to users (so data doesn't change)
  4. Migrate your data to Cloud
  5. Verify that things look good
  6. Release Cloud to the public

I would keep your Jira Server instance around for a few weeks, because there will be that person that claims their data didn't migrate.  You want to be able to compare with what was originally in Server to prove them right or wrong. I hope that helps. Good luck!

Like Sri Kumar likes this
Nicolas Mourier
Contributor
February 28, 2022

Thanks a lot for your answer @Dave Theodore [Coyote Creek Consulting] 

It's going to help me a lot !

Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 26, 2022

Hello, Nicolas

We are a Platinum Atlassian Partner in New Zealand, and have run multiple Server to Cloud migrations for our customers, so of which are quite big and would fall in the top 4% of all Atlassian Cloud instances size-wise.

Our of these we've done both site import and JCMA migrations. Yes, do not mix the two – the results as we found out are a disaster.

Create a run book. We (ab-)use Product Requirements blueprint in Confluence, with "User Story" column reserved for specific steps, each one with a clickable [ ] task box. When the run book is executed we mark down the start/stop timestamp of each step.

A migration is not instant! The latest JCMA migration of ~1500 users, 280 projects, 28Gb of attachments and two apps took 64 hours and ran from 6pm Friday to 8am Monday.

The main pain point for a migration are the 3rd party apps – consider yourself lucky if you are not using any on Server. If you do not have apps – you may still try the full site import option. If you do have apps – JCMA is much more likely to be the way, especially if the apps support automated migration. You should reach out to vendors and confirm they do not have scheduled downtime/maintenance for the weekend(s) you choose.

I suggest to plan for multiple test migrations. In our experience it takes about 5-6 of test ones to get it absolutely right. This number may be going down with JCMA getting more and more features, but still so far it's not a one-off affair.

Do let Atlassian Migration Support know 2 weeks in advance when you are doing the TEST migration and most importantly the PROD one. 

With JCMA, you should also look out for things like Filters, Boards, Dashboards – you will have to use JCMA dark features for that.

Atlassian Access and the overall dance around it – deactivating the users who somehow got into Cloud over the years in bulk before migration, integrating with your IdP for SSO and User Provisioning (if supported by your IdP), breaking this link before migration (so JCMA can add users into groups that will eventually be populated from your IdP) and restoring the link after – is important to get right.

In general configuring your Cloud site permissions, including integration with IdP is an important step to get right. See here for some of our recommendations: https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417

We also always re-key Jira as far as groups are concerned – often in Cloud there will be no "jira-users" group coming from the IdP, while your Server data may be using this group everywhere in permissions/restrictions, notifications schemes, workflows.

Switching off mail connectivity in Cloud while you doing your TEST migrations and until you've accepted the PROD one is an important think to remember, so Cloud doesn't steal your PROD emails from the PROD mailboxes.

Yes Confluence Server, once Application Links are re-pointed to Jira Cloud will continue to work.

Once (if) you move Confluence to Cloud, you will need help from Atlassian support to update links in Jira (and Confluence) to make two products work together well again.

Do not forget Jira Cloud looks and behaves differently from Server, so besides UAT you may want to plan for some training for the teams you are moving over.

In general, I suggest not to take on this journey alone, and involve a nearby Solution Partner

Nicolas Mourier
Contributor
February 28, 2022

Thanks a lot for your anwer @Ed Letifov _TechTime - New Zealand_  !

It's going to help me big time

Taranjeet Singh
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 28, 2022

Great suggestions based on your expertise, @Ed Letifov _TechTime - New Zealand_ !

Nicolas Mourier
Contributor
February 28, 2022

Hello,

I realize I should have add more information about the migration, so here they are.

We already have a free trial Cloud version that we emptied of all projects and groups

I have read here  that Site Import is no longer available for migration under 101 user, so  we are going to use JCMA.

I ran the Migration Assistant Home after reading the pre-migration checklist. I stopped at step 3 Migrate your data, here is the 'about your product'

firefox_O02syOF3oe.png

So it's a relatively 'small' migration, we do not have any 3rd party apps so I'm considering myself lucky :)

 

Considering the size would it still be recommended to run 5-6 test run ?

 

@Ed Letifov _TechTime - New Zealand_ I am not familiar with "mail connectivity in Cloud" what do you mean by that? Is it the notification email from JIRA ?

I'll definitely contact a solution partner

Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 28, 2022

@Nicolas Mourier You are lucky :) I would still run at least 1 test migration, verify everything thoroughly.

One thing to look out for – is any meta-data objects that may be present in Cloud before you start JCMA that will cause conflict with whatever will be coming from Server e.g. Resolutions, Project Role Names, screens and screen schemes, statuses, etc. You may want to rename everything you can to "X Old" so JCMA doesn't treat them as conflicting. In particular delete all custom fields (and empty the trash) that you can.

If anything after migration gets "(migrated)" suffix in the name – this needs investigation. It is only OK in custom fields where on Server you have multiple fields with duplicate names – these can be renamed after migration. In everything else – presence of such suffixes is red flag.

Like Nicolas Mourier likes this
Ed Letifov _TechTime - New Zealand_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 2, 2022

Most importantly – consider how you will be resetting the site repeatedly. For our bigger migration we use site import with an "empty" Jira and user overwrite.  However, as you pointed out the site import is disabled for smaller instances. You may need to reach out to support and ask them to enable the site import specifically for the purpose of site reset. Please note deleting Jira subscription knocks out something on the billing side of Cloud if your instance is on commercial billing or extended trial license, and the billing team is not 24x7.

Like Nicolas Mourier likes this
TAGS
AUG Leaders

Atlassian Community Events