Join us in Munich this March for Atlassian Connect: Cloud Bound! Register free here
Data Center upgrade guide
No organization is the same, and neither is your migration journey. Follow our step-by-step upgrade guide to ensure a smooth transition from Atlassian Server to Data Center.
Assess
Each organization has unique needs and requirements, so it’s important to understand your choices to plan a successful upgrade.
Assess Cloud and Data Center
As your first step, we recommend assessing Data Center and Cloud to find the best option for your organization. For many large customers, Cloud Enterprise is a great fit, offering increased user limits, advanced administration controls, and built-in security and compliance features.
For a personalized recommendation, take our migration assessment. We’ll ask you some questions about your requirements, then recommended the best pathway for you.
Our Cloud and Data Center comparison guide is also a great reference, providing a side-by-side comparison of the features, plus guidance on which option to choose based on your use case.
Have a detailed question about Cloud? Get in touch to schedule a Cloud consultation with a migration specialist.*
*Available to customers with Commercial or Academic licenses over 25 users or agents
Understand your architecture and infrastructure requirements
Decided on Data Center? You’ll need to to get to know the supported Data Center architecture and deployment configurations.
Data Center can be deployed in two different ways: non-clustered or clustered. Both allow you to leverage enterprise features and capabilities, but each option requires different considerations. Here’s a table that describes the differences between non-clustered and clustered architectures:
Non-clustered recommended
Infrastructure requirements
A non-clustered architecture enables you to upgrade to Data Center on your existing infrastructure, so you don’t need to make any infrastructure changes.
Recommended use cases
We recommend that all customers upgrade to Data Center using the non-clustered upgrade path. Customers can implement a clustered architecture once live on Data Center if needed.
Benefits
Unlock the enterprise features that don’t rely on clustering:
Non-clustered upgrades are typically where many customers begin their Data Center journey. We recommend taking advantage of this 2-minute upgrade to ensure a smooth transition.
Clustered
We recommend that all customers upgrade to Data Center first using the non-clustered upgrade path. Following a successful Data Center upgrade, customers can then implement a clustered architecture if needed.
Infrastructure requirements
You will need the following components to upgrade to Data Center in a cluster:
- Load balancer
- Application nodes
- File system accessible by all application nodes
- ElasticSearch node (Bitbucket)
Recommended use cases
- You require high availability
- You want to upgrade without downtime
- You expect to grow to XL scale in the short term
Benefits
Unlock the enterprise features that clustering can deliver:
- Enterprise features and capabilities
- High availability and failover – if one node in your application cluster goes down, the others take on the load, ensuring your users have uninterrupted access to the product.
- Instant scalability – Add new nodes to your cluster without downtime or additional licensing fees. Indexes and apps are automatically synced.
- Disaster recovery – Deploy an offsite Disaster Recovery system for business continuity, even in the event of a complete system outage. Shared product indexes get you back up and running quickly.
Review the difference between Server and Data Center products
While Data Center offers features that you may be familiar with, we’ve also built additional capabilities and extended the functionality of many Server features. Review the differences between Server and Data Center and get a sense of what new features will be available to you, and which will require a clustered architecture.
- Jira Server and Data Center feature comparison
- Jira Service Management Server and Data Center feature comparison
- Confluence Server and Data Center feature comparison
- Crowd Server and Data Center feature comparison
- Bitbucket Server and Data Center feature comparison
- Bamboo server and Data Center feature comparison
Evaluate technology decisions
Getting ahead of your technology decisions will speed up the design of a production-ready environment for your Data Center products that is tailored to your organization’s needs. Whether you’re going to deploy your Data Center products in a clustered or non-clustered environment, look at the infrastructure you’re currently using to run your products and consider if it makes sense for you to deploy on AWS, Azure, your own hardware, or moving to an orchestrated deployment using Kubernetes or Docker. If you decide to deploy in a clustered environment, you’ll need to start assessing the additional components you will need, such as a load balancer, shared file system, and application nodes.
For additional recommendations and resources that can help you evaluate your technology decisions, download our deployment checklist.
Get to know your cloud provider
Deploying on a cloud vendor, such as Amazon Web Service (AWS) or Microsoft Azure, may be new for your organization. If you plan to use a cloud vendor, we recommend taking the time up front to:
- Understand the deployment and architectural pieces of your Data Center products
- Learn about different configuration management tools, such as Ansible Chef, Puppet, or Salt.
Both AWS and Azure offer training courses that can help you learn more about the platforms. While it’s not required, you may even find it beneficial to have someone on your team become a certified solutions architect. For more information, here are a few resources that you can check-out:
Plan and prep
Now that you’ve chosen your Data Center path, you’re ready to start creating a detailed upgrade plan.
Build your team Required
One of the most important parts of this journey is assembling the right team and doing so as early as possible. Upgrading to clustered architecture will impact multiple teams across your organization, and requires everyone’s collective involvement.
Once your project team is assembled, it’s important to align the team on shared goals and build your timeline with an agreed-upon target date.
There’s no definitive answer to which roles and how many people should be included on the team. However, it’s important to consider the following areas of expertise when assembling your team:
Application admin
Roles
The application admin handles the day-to-day administration. They have in-depth knowledge of the product, care about performance, reliability, and evaluate and maintain Marketplace apps. They may also work closely with end users to understand their needs and provide assistance or training.
Responsibilities
- Makes decisions about apps that aren’t Data Center approved.
- Verifies that the users and permissions are maintained correctly throughout the transition.
System admin
Role
The system administrator handles everything from the infrastructure to the product interface. They are concerned with backups, storage, network, and performance.
Responsibilities
- Provisions the hardware (physical or virtual) needed.
- Installs and upgrades Atlassian applications.
- Verifies functionality and performance during testing to ensure that Data Center is operating properly.
- Ensures all cluster nodes are accessible and the load balancer is configured correctly.
- Sets up any logging, monitoring, and security tooling.
Project lead
Role
The project lead has a deep relationship with the business and knows how and why the product is used to meet company objectives. They also know how to make the right tradeoffs to maintain governance across products.
Responsibilities
- Keeps the project on track with key milestones and estimated dates to achieve them.
- Owns the schedule, ensures task completion, and resolves cross-functional issues.
- Communicates project updates to stakeholders and announcements to end users.
- Works with primary stakeholders in the purchase of Data Center.
If you’re deploying Data Center in a clustered architecture, you may want to also consider having team members with technical expertise in the following areas:
- Network engineering: Reviews, specs, and build out your infrastructure.
- Database administration: Configures and implements database back up strategy.
- Site reliability: Establish instance uptime, performance, and disaster recovery operations.
- Security: Ensure compliance with security standards (VPN, firewall, etc).
Need additional team members
Atlassian offers support if you need help with your upgrade.
Free with Data Center
Priority Support: Your critical support issues will route directly to Senior Engineers, who are committed to delivering higher SLAs, faster triage, and faster resolutions. Priority Support is included with Data Center subscriptions to Jira Software, Jira Service Management, Confluence, and Crowd. It is also included with Bitbucket Data Center subscriptions with 500 users and above, and Bamboo Data Center subscriptions with 100 agents and above.
Atlassian Community: Prefer to crowdsource? Find answers, support, and inspiration from other Atlassian users. We recommend that you join the Enterprise community group for stories, tips, and best practices for using Atlassian products at scale.
Paid support resources
Atlassian Advisory Services: Make your transition as smooth as possible with guidance from experienced Atlassian advisors. Your Atlassian advisors will dive into your configurations and workflows and provide you with valuable best practices, insights, and technical guidance. Together you’ll develop a comprehensive upgrade plan to confidently execute.
Premier Support: Looking for an elevated level of service? Atlassian Premier Support offers our highest level of support with 24/7 access to a dedicated Senior Support Team.
Solution Partners: Looking for a one-stop-shop? Enterprise Partners conduct hands-on system integrations, deployments, and upgrades. Enterprise Partners are a great option for organizations with complex requirements or that are looking for onsite help. Visit our Partner Directory to find a partner that is right for you.
Build a timeline Required
Here are the basic timelines that you can use to gauge how long your upgrade should take.
| Non-clustered | Clustered |
---|---|---|
Planning | Non-clustered 0–2 weeks | Clustered 1 month + |
Dry run | Non-clustered 0–1 week | Clustered 3–6 months |
Go live | Non-clustered 0–1 week | Clustered ~6–9 months |
The timelines included are based on a number of our customers who have successfully upgraded to Data Center, but it’s important to note that the actual timeline will vary based on factors unique to your environment including, but not limited to, environment size, complexity, and preparedness.
Review your Server instance and optimize your infrastructure
Regardless of how you choose to deploy Data Center (non-clustered or clustered), you want to take the time to review your Server instance and understand if there are any areas that you want to optimize during your migration.
Evaluate the size of your instance Required
Data Center is built to support the needs of teams at scale. To ensure that you set up your infrastructure for a successful upgrade, review the sizing of your current Server instance, and adjust based on profile size recommendations. As you adjust your size, consider their rate of growth so that you can scale accordingly.
Benchmark your Server instance Recommended
Take a baseline measurement of your system’s existing performance. That way, if you choose to use features like custom field optimizer or archiving, you can measure the performance improvement between Data Center and your existing Server instance.
Fine-tune your Server instance Recommended
Even if you plan on immediately taking advantage of our capabilities (like archiving and custom field optimizer) to cool your instance down, you should fine tune your server instances before you move. Look at your current Server instances and take the time to identify and correct any suboptimal configurations. Spending this time early on will help set up a stronger foundation for your Data Center instance.
Assess and update governance Required
How users interact with the products also affects the performance. Before deploying Data Center, assess these usage characteristics and determine whether you need to establish any restrictions on things like scripts that make REST calls, or other integrations, to protect performance.
Document current processes Recommended
After instance tuning, it’s time to document your Server environment. This documentation can help guide configuration decisions in your Data Center upgrade, influence process modifications, and determine whether issues found are new or already existing.
Audit your current apps Recommended
Using a large number of apps may degrade the performance of your instance. We recommend that you audit and remove any apps that aren’t crucial, to increase overall system performance. You’ll also want to make sure your apps are compatible with Data Center, as your apps will need to be upgraded to a Data Center version if one is available.
If there currently isn’t a Data Center version of your app, you can continue to use your Server app, but you will be required to upgrade if one becomes available.
You'll want to consider both the current and future price of your apps as part of your Data Center total cost of ownership. You can use our Data Center business case toolkit to help with your assessment.
Define your Data Center environment Required
Application layer
Instances and locations
- Do you want to federate or consolidate your instances?
- What does your future growth look like?
- Do you need to have any data isolation?
- How many environments does your team have, such as staging or production environments?
Instances profiles
- How many people are going to be accessing your instance?
- Where are your teams going to be located?
- How much data is currently in your instance and how much data do you plan to add to your instance?
Apps, integrations, and customizations
Do you need all of them, or is this an opportunity to simplify?
Infrastructure layer
Instance sizing
- What are your future growth projections?
- Are there times when you have lower levels of user traffic?
For more information, here’s our node sizing overview.
Account structure
- Which accounts should your environment be deployed on?
- Do you want different accounts associated with each of your environments?
- Do you want your Data Center products to use the same account as your other CI/CD or collaboration tools?
Governance model
- What does your governance model look like?
- What are your minimal system standards?
- Are you using centralized logging?
- What are your user management needs?
Consider using AWS landing zone and AWS System Manager as part of your governance model.
VPC
-
Do you want to use a new virtual private cloud (VPC)?
Whether you want to deploy in a new VPC or use an existing one, you can leverage the Atlassian Standard Infrastructure (ASI) template.
- Are there any network principles that you want to change, such as limiting public internet access and internal IP addressing for office and VPN network routing?
- Should you use TLS certificates?
Geography
-
If using an existing VPC, have you come up with a plan for office and VPN network access?
We recommend that you allow access from all offices and VPNs as your product usage will most likely grow over time.
Direct Connect
- Do you want to use Direct Connect to help with performance and security?
- How much data do you need to move from your server instance to Data Center?
AWS Snow Family may be a resource that you may want to consider if you’re moving large amounts of data.
Business continuity and disaster recovery
Backup
What does your backup strategy look like?
We recommend that you use a combination of both your existing backup strategy and backup capabilities built into AWS. For more information, see:
AWS provides infrastructure services that are less prone to singular outages.
Regional failover
Do you need to implement cold, warm, or hot sites in different regions?
Typically, your disaster recovery needs are met by having your services run over multiple availability zones, but you may want to mitigate regional outages too. As you’re deciding if you want to implement these sites in different regions consider the following:
- Cost of infrastructure and data transfer
- Speed of recovery vs AWS
- Time spent maintaining and testing the recovery site
- Cost of running the site
Upgrade to Data Center (non-clustered) recommended
We recommend that all customers upgrade to Data Center using non-clustered architecture. Non-clustered upgrades are a faster and more simplified upgrade option, providing quicker access to Data Center’s security, support and enterprise features.
Upgrade your apps
If you have any Server apps installed on your instance, this is where you should upgrade to a Data Center approved version of each app, where available. If you upgrade your Data Center product license before you upgrade your apps, they may stop working.
Upgrade your product license
Upgrading to Data Center in a non-clustered environment is very simple, and enables you to immediately use enterprise features and capabilities that don’t require clustering.
To upgrade, simply go to the admin section of your Server product, and enter your new Data Center license key. You can come back and set up clustering later, if you need to.
Non-clustered Data Center is compatible with the following product versions:
Jira Software: 6.3 or later
Jira Service Management: 4.0 or later
Confluence: 7.2 or later
Bitbucket: No minimum version
Bamboo: 8.0 or later
Crowd: 3.0 or later
**If you are on an older version, we recommend reaching out to support for assistance with your upgrade.
For product-specific guides on non-clustered upgrades, visit our documentation:
- Upgrade to Bitbucket Data Center
- Upgrade to Crowd Data Center
- Upgrade to Confluence Data Center
- Upgrade to Jira Data Center
Once on Data Center we recommend you upgrade to the latest Long Term Support (LTS) release available for your product.
Upgrade to Data Center (clustered) not recommended
We do not recommend initial upgrades to Data Center on clustered architecture due to the complexity of upgrading. We recommend that all customers first upgrade to Data Center using the non-clustered upgrade path. Following that, customers who require a clustered architecture can begin their implementation.
Once you’ve upgraded to Data Center on non-clustered architecture you can then implement a clustered architecture if you require high availability.
Get the infrastructure you need for your cluster
To deploy Data Center in a cluster, you’ll want the following components:
- Database
- Load balancer
- Application nodes
- Shared file system
- ElasticSearch node (Bitbucket)
Load balancer
The load balancer is the first thing that your users’ requests hit if you’ve deployed in a cluster. Requests come into the load balancer and the load balancer then distributes each request to the application nodes. You can use either a hardware or software-based load balancer. For both software and hardware solutions, the load balancer should be linked to the application cluster using a high-speed LAN connection to ensure high bandwidth and low latency. All software load balancers should run on dedicated machines.
Data Center products assume that each user’s request will go to the same node during a session. If requests go to different nodes, users may be unexpectedly logged out, and they could even lose information stored in their session. Therefore, it is required to bind a session to the same node by enabling cookie-based “sticky sessions” (or session affinity) on the load balancer. When using cookie-based sticky sessions, you can use the cookie issued by the product, or you can use a cookie generated by the load balancer.
Add an extra layer of protection and prevent the load balancer from becoming a single point of failure by adding redundancy to your load balancing solution. You can do this by setting up two load balancers in an active-passive configuration, using a virtual IP address across both load balancers. If the active load balancer fails, it will failover to the passive load balancer.
For more information, see our load balancer configuration options.
Application nodes
Application nodes are where the actual product lives. Each node in your Data Center cluster must run on the same version of the product and be located together to keep latency to a minimum. However, you can enable a content delivery network (CDN) to support the performance of your geo-distributed teams. These nodes should be configured in a cluster, acting as one, to serve the product to your users. The number of nodes in your cluster depends on your needs and how you configure your product. Typically, we find that between 2-4 nodes are sufficient for most clusters, but use our node sizing guides to help you make the right decision.
Bitbucket requires an additional application node specifically dedicated to ElasticSearch, which enables code search.
Shared file system
The shared file system is where data that should be accessible from any application node is stored, such as attached files, and git repositories.
In a Data Center environment, you need to set up your shared file system as its own node. You can use any NFS based NAS or SAN program for your shared file system, but we recommend NFS3 to maintain your performance. Just be sure to stay away from distributed protocols like DFS, as these are not supported.
Build your cluster
It’s time to build your Data Center cluster. In addition to setting up each of the various components in your cluster (application nodes, load balancer, database, file system), you also need to size the application nodes in your cluster based on your performance requirements.
We’ve put together some sample configurations you can reference. Atlassian does not endorse, approve, or recommend any specific vendors or configurations. These are provided as a reference. If you’d like more hands-on guidance around configuring your optimal environment, see if working with a Technical Account Manager, Premier Support, or a Partner is right for you.
Create a staging environment
To successfully upgrade to multi-node, we recommend creating a staging environment to try out Data Center before going live in production.
Your staging environment should closely replicate your production environment, including any reverse proxies, SSL configuration, or load balancer. You may decide to use a different physical server or a virtualized solution. The main thing is to make sure it is an appropriate replica of your production environment.
For detailed instructions, see:
Upgrade your apps
If you have any Server apps installed on your instance, this is where you should upgrade to a Data Center approved version of each app, where available. If you upgrade your Data Center product license before you upgrade your apps, they may stop working.
Test the Data Center
The testing phase is a fundamental, though intensive step in deploying a clustered Data Center instance. In order to confidently deploy Data Center to production, the team should run through an iterative set of functional tests, integration tests, and performance tests to vet the Data Center installation.
Don’t skimp — a thorough testing phase will speed up your production deployment and allow you to account for unforeseen circumstances. Run multiple User Acceptance Tests (UATs) if necessary until you’re fully confident with going live.
Learn about performance on Data Center products:
Go live in production
Now that you've upgraded your testing environment to Data Center, you're ready to go live in production.
Before you complete your upgrade, check that your production environment matches your testing environment so that everything works correctly on production, as you'll be completing the same steps as you did during the testing phase.
You’ve deployed Data Center in a cluster!
For detailed technical guidance, visit our documentation:
Upgrade to the latest Long Term Support release
Once live on Data Center, we recommend you upgrade to the latest Long Term Support (LTS) release available for your products.
You can find the most recent LTS version here:
Talk to an expert
Have a question about your migration options or path? Get expert guidance from our team of migration specialists.