This article was written by Kamil Beer, an Atlassian Engineer at iDalko.
Migrating Atlassian tools is always a hot topic. Changing your deployment type is certainly possible, but it requires some consideration beforehand. So in this part of our series “Best practices maintaining an Atlassian Stack”, we analyze what to consider when we want to migrate Jira to another deployment and what steps to take first.
In the last article, we covered the Atlassian tools deployment models and their ups and downs. But in case you already have a Jira instance up and running, keep reading!
So maybe you found out that a critical feature you need in Jira isn’t on Cloud. Or that you need to update your Confluence without scheduling Server downtimes all the time. Or that your numerous dev teams need a better performing, always-online Bitbucket – perhaps in a Data Center. This article is for those stuck in this situation to help them successfully migrate their Jira instance.
Moving your application from Cloud to Server, vice versa, and even to Data Center is certainly possible. But every platform has different requirements, behaviors, and even looks different, so it’s necessary to first put together a game plan. What is required to execute a migration in the best way possible?
- Staging server migration
- User acceptance testing and training
- Production server migration
- Post-migration support
This article covers the first two steps regarding the preparation; Analysis and Cleanup.
Analyze the New Platform before you Migrate Jira
The first step of this journey is about taking a hard, honest look at whether the new platform suits your needs, what will change, and if migrating your Jira is even possible. There are several angles to this:
It’s necessary to take into consideration potential price change is essential. To illustrate, we compared the costs of Jira Software for 100, 1000, and 2000 users on Cloud, Server, and DC. We included five popular apps: Tempo Timesheets, eazyBI, JMWE, ScriptRunner, and Xray, and created a quote for five years (June 2020).
For Cloud, we used Standard annual pricing and saved two months of payment from the monthly model. For Server, the prices contain maintenance paid every year. You can, however, not pay for the maintenance and still use the application.
No discounts have been applied, so these are the official prices from Atlassian in USD, cumulative over the years.
You can also create your own quote here:
During the first two years, Cloud was priced similarly to Server. From the third year on, the price difference leaned more in favor of Server. The hosting and staff costs aren’t included in the Server price, nor is the decision to not renew maintenance. Doing so might be useful if you’re isolated behind a firewall and less vulnerable to security exploits.
The 1000-user tier is available on Cloud Standard. On Server, you can buy either a 500 or a 2000-user license. But even here, we see that the more time passes, the better the price for Server gets. The 1000-user Data Center remains priced mostly better than its 2000-user Server counterpart.
Compliance and Security
What should you also consider when changing deployments is the GDPR. If you’re in Europe and want to migrate to Jira Cloud, think twice. Many companies sign contracts or NDAs with customers or suppliers saying that confidential information remains on local servers. This drastically changes in Cloud, as data may be stored anywhere. Thus, all those agreements will need to change as you move from Server/ Data Center. In enterprises, these revisions might take years.
If you work behind a firewall, you will need to whitelist 7 domains, a large number of IP ranges, the required Amazon/ Cloudflare services, and various third-party app sites for Cloud. Atlassian instructs that you should allow everything with a service name “Amazon” or “Cloudfront”, several IPs to receive notifications, and yet another set of IPs for Trello and Bitbucket. You can read more about it here. You’d have to do that on every firewall. Even the Server products will need whitelisting, mainly for the Atlassian Marketplace.
Another point is your user base. Let’s say you use Crowd, connected to your Active Directory, and providing SSO on Server. Or you’re using Atlassian Access with Azure AD or GSuite and are moving on Cloud. The crowd isn’t available on Cloud – and you will need to buy an extra app to integrate GSuite and ADFS on Server. What will be the authenticator (or SSO provider) post-migration?
Also, Cloud Standard supports only 5000 users, in case you have an enterprise Server/DC deployment and want to migrate to Cloud, so beware!
If you are migrating to Server instead, know that you will have to strengthen your application server yourself. That means building up a proxy, providing an SSL certificate, changing ports for SSH, deploying an application like fail2ban.
Most of us resist change, and changing an application you use daily is a big one. Users will be startled even by different colors, not to mention various buttons not being where they used to be. And the users finally learned where is what and how it works.
Or they might hate the new design. There was a significant pushback after the 2017 Cloud UI change, so much so that Atlassian reverted to the old UI at the end of 2019. User resistance is something to be prepared for, no matter which platform you’re migrating to.
You can mitigate this by providing learning resources for users and giving them early notice. Atlassian has a great library of free training and we at iDalko have prepared a user guide for you with which you won’t get lost!
If you use integrations on Server, then they might not work on Cloud at all. Direct database access will not be available, so you will have to rebuild what you can in REST API. Legacy systems will be heavily impacted and integrating COBOL or FORTRAN software just seems hard to imagine. Same for custom hacks or apps. It could be impossible to transfer them on Cloud, Atlassian vets all Cloud apps and upholds strict standards for them. And well, apps on Cloud and Server are written differently, too.
Cloud apps are written in “Atlassian Connect”, a framework different from the Java one on Server. On Server, an app is installed directly into the software, but a Cloud app is a separate web application connected, for instance, to Jira by REST API. Read more about this type of deployment here.
Apps like Power Admin, JMCF, or Rich Filters simply do not have a Cloud variant. However, it’s safe to say that as the more popular the app, the higher chance is to see it on all deployments. Some apps have limited features, like Scriptrunner’s very different feature set. Others might not migrate data correctly, easily, or at all.
While you can’t easily transfer all apps/ integrations from Server to Cloud or vice versa, it’s useful to first test whether all features have been migrated using a demo instance. And second, to check all app differences in the vendor’s documentation.
- How much downtime can you afford? Cloud Standard has no guaranteed uptime.
- What monitoring changes (via Nagios, Grafana…) will you need to do?
- When migrating from Cloud to Server, your application administrator will acquire extra duties – he should administer the server, too.
- How will you maintain your backups when moving from Jira Cloud to Server?
Did the analysis go well? Good! The next step is tidying your instance up so that you do not carry over old data or unused configuration. Even if you didn’t migrate your Jira in the end, it is a helpful procedure to do once or twice a year.
So, how to do it? There are many ways, but let’s mention the most common steps. We will properly focus on how to perform a cleanup in one of our next articles.
Archiving Projects, Spaces, and Repositories
If you have been using Jira, Confluence, or Bitbucket for some time already, chances are you have many of these that users don’t use anymore. These may be finished projects, old documentation or training tools, duplicates, and so on that are unnecessarily taking up database and file space.
A good way to determine if a Jira project is used is to sort its issues by their updated date. With a third-party app like Rich Filters or Power Admin, finding the last updated date is even easier.
Confluence shows space activity on every space’s default home page. If you use Better Content Archiving, you will see which pages are edited and read in each space. In Bitbucket, every repository has a last commit date.
Archive Jira/Confluence/Bitbucket by simply taking a backup, confirming its integrity, and delete the old content from production.
After removing the projects, many workflows or custom fields won’t be used anymore. You should remove them, as the admins will later have trouble finding the ones they need. And having too many fields slows Jira down when searching and viewing issues. Watch this video to find out more.
To check if a custom field is used, a handy query to use is <name of field> IS NOT Empty to see how many issues actually use this custom field.
This will save you money and improve security. Whenever a user leaves or stops using the application, the best practice is to deactivate them. However, sometimes you may forget and their accounts will remain active. As an access point, this is a security risk and it makes license usage higher. Unused accounts should be removed before you migrate your Jira instance.
It isn’t easy to check which users are active, unless you want to dig in the database (and only on Server/ Data Center) or manually check every user. A useful app that shows users who haven’t logged in for some time or at all is User Management for Jira, available for Jira, Confluence, and Bitbucket.
When migrating to Cloud, don’t migrate misconfigurations. So unless you will rebuild everything from scratch, checking the application logs and the instance integrity helps identify errors in the current configuration and their cause.
You can either read your logs manually or use the Jira/Confluence Log Analyzer that scans your log for errors and points you to relevant Atlassian KB articles. You can also use the free Integrity Check app for yet another scan for misconfigured boards, dashboards, and Jira projects.
Thousands of apps are available, free to use for 30 days. So it’s tempting to try them all out. They will remain installed after the trial period, though. Or maybe you run an app that was popular once, but users stopped using it. Don’t migrate unused apps that take space and raise the costs. Same with the apps with redundant features, like Jira workflow modifiers or Confluence table enhancers.
Apps that bring new features and create new objects, like portfolios in Portfolio for Jira (now Advanced Roadmaps), BigPicture programs, or Object Schemes in Insight can be audited by checking the last updated date of each of the objects they create, in addition to simply asking their users.
Lastly, there are apps without a clear usage trace, like various gadgets or macros. Search for them in the database, using the apps’ name. For example, type in com.qotilabs.jira.rich-filters-plugin to search for all Rich Filters gadgets.
In the first part of this series of articles, we covered the Atlassian deployment models and their upsides and downsides in detail to help you choose the right one for your use case. Once you’ve decided which deployment model suits you best, it’s time to migrate Jira to your desired destination. But the migration would be way smoother and less time-consuming if you prepare for it, analyze the platform and the possible changes, and run a good clean-up.
Are you all done and ready to migrate your Jira? Great! Let’s do it following this step-by-step guide.