Flat illustration of a man with a laptop sitting cross-legged on top of a motherboard

How to migrate from Atlassian Server to Data Center

End of Life is near for Atlassian Server. Are you looking to do a seamless migration to Data Center? Kantega SSO will help you get started.


Atlassian Server is being phased out and will be completely discontinued by 02.02.2024 for most products (Jira, Confluence and Bitbucket). Many organizations therefore need to migrate from Server to Data Center. This also applies for the Kantega SSO application, and our guide will help you move in a few smooth steps.

Kantega SSO Server and Data Center are in the same software package as the Atlassian product, which means you don't have to download the Data Center version of Kantega SSO if it is already deployed.

Update single node

If you have upgraded to a Data Center license in an existing single node installation, all you must do is perform an update to the same license.

Buy Data Center License

Purchase a Kantega SSO Data Center license for Jira, Confluence or Bitbucket in the Atlassian Marketplace for the same number of users as your Atlassian product license.

The Atlassian license does not restrict number of nodes in the Data Center. You may also use a trial license to test the migration.

New features will be available in Jira, Confluence and Bitbucket. These are documented by Atlassian themselves, and Kantega SSO has no specific Data Center features you must update.

Set up cluster

If you have set up several nodes in a Data Center cluster, you have already created a shared folder for the nodes (shared home). Kantega SSO is deployed in these shared directories and is populated in the cluster automatically. The set up for the license is the same way as with a single node. 

It is possible to have a shared home folder and a local home folder in each deployment. If Kantega SSO is deployed in the local home folder, the configuration of Kantega SSO Enterprise is not populated to the other nodes in the cluster.

The <local home>/Kerberos folder must then be moved to the <shared home> folder of the cluster. Do this on one node, and the KSSO configuration will be populated to all nodes. 

Unfamiliar environment

In case of deployment in an unfamiliar environment – keep the Kantega SSO configuration from the old Server.

Take a backup of the <home>/Kerberos folder and restore it on the <shared home> folder in the cluster. 

If you set up a load balancer / reverse proxy for the cluster and the A-record (canonical name) changes, then the Kerberos configuration must be updated.

To use a new base URL there are several updates that need to be done at the Identity Provider to maintain the secure SSO connection. The safest approach in this case is to install Kantega SSO for Data Center and do a new setup.

You can also read more about a migration in the Atlassian documentation site:

You might also find Kantega SSOs migration troubleshooting guide helpful:

Feel free to reach out to our support desk or servicedesk@kantega-sso.com if you have any more questions or need help with your migration.

Similar posts