Full Atlassian Suite Upgrade/migration

[Rodrigo Valdés]

Upgrade/Migration of an Atlassian Suite.

Hi, me and my Team are working to plan and execute Upgrade/Migration of an Atlassian Suite in a Customer. Current environment is comprised of (Jira 6.X, Confluence 6.x, Stash 3.x, Bamboo 5.x). Objective of the project is migrate current architecture and upgrade all applications to latest versions, in order to scale current usage to a broader internal end user base.

At this point, our team is gathering all information from current Products suite (Atlassian and other tools like Static Code Analizers, Artifact Repositories Tools). And designing an strategy in order to execute the best platform migration posible.

As you can see, current application versions are very old. Reading Atlassian documentation, we can see that there are several step to pull out a succesfull migration/upgrade of individual Atlassian products.We also have seen that there are some migration paths that require extra migration steps between source version to destination. i.e: Jira 6.0 -> Jira 7.0 -> Jira 7.12.1

From doc research, typical upgrade/migration workflow can be defined as a set of steps like following:

• Info Gathering
• Planning,
• Cloning in a test environment
• Perform the upgrade in test.
• Verify.

Then, if everything went well with the testing, same procedure is executed in Production Instance.

Do you think that this is a correct approach for individual product migration/upgrade?.

If this approach is correct. What about the other products,meanwhile?. We have not seen so much information regarding migration escenario of complete Suites. Should those be also migrated and upgraded using the same approach in parallel? Or can this be done in a secuential way to minimize risk?.For example, Upgrade/Migrate Jira in a weekend, next weekend Confluence and so on?

Can you share your views and suggestions in order to define a good strategy in described scenario.

Thanks.

Best Regards
Rodrigo Valdés

[Keri · Accepted solution]

Hi Rodrigo,

I’m glad to hear that you’re putting a lot of work into planning this migration.  Testing is definitely the way to go!

I’m not sure here how your applications are currently hosted - if there is one application per physical server, or whether they’re sharing a database server or other configurations? I only ask as most of these upgrades will have different supported platforms.

One major consideration will be the application links between applications - the following matrix shows the versions of application links held on the different applications: https://confluence.atlassian.com/applinks/application-links-version-matrix-779174762.html

For example, the versions of Bitbucket Server (Stash) you’re currently using uses AppLinks 4.3 - so the latest version of Jira may have issues communicating with it. So you may wish to plan your upgrades around which functionality is most critical to your business.

If you want to upgrade all of your applications at the same time or staggered really depends on the number of people you’ll have available to make sure that the upgrades are successful and the amount of preparation done in advance.

It sounds like you’re carefully planning this, good luck with the upgrades and reach out if you have any specifics with upgrading each product!

Cheers,
Keri

[Thomas Burke]

The Atlassian support structures are hideously lacking in this respect of coordination.

We have a simple user case, 3 on-premise server products Bitbucket, Jira, and Confluence all integrated into an on-premise Active directory.

There is not one source of guidance for this use case migration.  Seems there are  4  siloed entities  we need to speak to a: 

• Bitbucket  Team
• Confluence TEam 
• Jira Team 
• AD on-prem  / Atlassian Organization team

and none of the above willing to get on a call 3 way to determine what needs to happen first.

I mean this is a big company, this needs to be written in a clear migration path for the use case.  I do not want to ask a simple question like with these  3  should happen first and how in turn be sent to 2  or 3  different teams, is ludivrous.,  Is at the point out leadership team is sying stop lets look for another solution  -  so sad.