Upgrade SW versions first, then add more user licences - or the other way around?

Question

Hi there,

We have just over a year ago (the licences has hence just expired) installed a basic package with a few Atlassian products, all on the up-to-10-users entry level or similar.

Products and versions we have now:

Jira v4.4.1#660-r161644

GreenHopper 5.7.1

Confluence 3.5.13

FishEye 2.7.11 Build:20120227023831

Crucible 2.7.11 20120227023831

Bamboo 3.2.2 build 2602

All of it now running on a Linux box with Apache.

We are now in the need to:

* Upgrade SW versions (on most products)

* Renew the support/upgrade licences

* Add more user licences (at least for a few of the products)

* We would also like to add a few new programs and plugins.

We would like to:

* Increase the number of users in Jira and Confluence to 25.

* I suppose that means that we also need to have 25 licences for GreenHopper?

* Keep the number of user licences to 10 on the other products.

* Introduce the Crowd product so that we can have single sign-on integrated with our Windows Server. This means moving the user/password management from Atlassian to Windows (I suppose?)

* Perhaps later on also install the Salesforce (Jira plugin) and Sharepoint Connector (Confluence plugin)

My question is about your recommendation of in what order and steps to do all these things!

Regards,

Thomas

Nic Brough -Adaptavist- · Accepted Answer

The new licenses will be compatible with all versions, so don't worry about the order too much.  However, I'd be strongly tempted to do them first for one reason - you can't upgrade past the end of the license.  For example, if your license ended yesterday, and Atlassian release Jira 5.2 tomorrow, you can't upgrade to it.  You can't go higher than 5.1

You are correct about Greenhopper and Jira - you will need to make sure they have the same number of seats.

If you implement Crowd, then think of it as a two-part thing.  First, you can remove user maintenance from the individual services and move it all into Crowd, which makes it all a lot more simple and centralised.  The second step might be to integrate Crowd with some other system, so that it takes it's data from there (i.e. your Windows stuff) instead of using a local independent user base.  I'd think of it as two distinct pieces of work, even though you might end up implementing them simultaneously (makes it easier to break up the work into manageable chunks, and debug stuff - if you can say "crowd and windows are fine, but it's not talking to Jira", that's easier to debug than "Jira won't accept my password")