Atlassian Data Center migration plan

This article provides a high-level process plan for migrating from a single-node deployment to a clustered Data Center deployment. The purpose is to provide an overview and potential timelines for project activities before, during, and after the migration process. It covers enlisting personnel, evaluating technology options, and ensuring that the current Server application is ready for migration.

The timelines discussed in this article are based on a number of our customers who have successfully installed Data Center. However, note that your actual timeline will vary based on factors unique to your environment. These include your environment size, complexity, and team preparedness.

A deeper technical discussion into the technology options and installation configurations are out of scope for this article.

tip/resting Created with Sketch.

Do you need to migrate to a clustered Data Center deployment?

If you have an existing Server installation, you can still use its infrastructure when you upgrade to Data Center. Many features exclusive to Data Center (like SAML single sign-onself-protection via rate limiting, and CDN support) don't require clustered infrastructure. You can start using these Data Center features by simply upgrading your Server installation’s license.

For more information on whether clustering is right for you, check out Atlassian Data Center architecture and infrastructure options.

Migrating to a clustered Data Center will have an impact on:

  • your users' experience and workflows
  • various stakeholders throughout the organization
  • other infrastructure components


This timeline shows the phases of a successful implementation. It identifies what to expect throughout each phase and ensures that the implementation front loads as much staffing, planning, and decision-making as possible to manage problems as they arise throughout the process. Customers who follow this process tend to have a more productive and positive experience when deploying to Data Center.

A Data Center migration is either:

  • in-place, where a single Server application is deployed as a multi-node Data Center application, or
  • consolidated, where multiple Server applications running on isolated nodes (for example, different instances of Jira being used by different teams) are re-deployed as a unified, clustered, Data Center application

This document focuses on the in-place migration process. If you need to consolidate instances in your migration, see Overview of Atlassian Data Center instance consolidation.

Build a project team

Enlist people and align the team on the Data Center goals.

Enlist people

An ideal Data Center deployment is a fully fledged project with defined roles and responsibilities across teams. As early as possible, you should communicate with individuals and stakeholders who are interested and impacted by a move to Data Center. Where possible, recruit and enroll these people to be a part of the process. Here is an overview of roles that will make the process more successful.

Executive SponsorGiven the scope of migrating to Data Center, it will be useful to have executive buy-in for the project.
Steering CommitteeA project steering committee provides strategic and tactical guidance.
Technical Product/Project ManagerThe technical product (or project) manager owns the schedule, ensures task completion, and resolves cross-functional issues. This person also communicates project updates to stakeholders and announcements to end users.
Technical Account ManagersAn Atlassian Technical Account Manager can provide guidance on the deployment plan and ensure that the right parts of the customer organization are involved in the process.
Power UsersThese are often Jira project administrators or Confluence space administrators. They will be crucial in verifying functionality and performance during testing to ensure that Data Center is operating properly.
Helpdesk, SysadminsFrontline staff address L1 support issues that may arise during migration, allowing the Atlassian product administrator to focus on the more critical issues during the process.
Database Administrator
The Database Administrator (DBA) provides frontline support during the process as well. The DBA also reviews and updates the organization's disaster recovery plan to align with Data Center's DR operation.
Network EngineerThe network engineer analyzes connectivity and updates networking requirements for Data Center. The network engineer can also provide expertise and guidance on selecting and configuring the load balancer, which is an essential component in Data Center.
Site Reliability EngineerThe SRE ensures that Data Center properly operates and scales with the rest of the organization's technology infrastructure.
Security EngineerThe security engineer ensures that Data Center adheres to the organization's security practices.
Premier SupportAtlassian Premier Support provides fast 24/7 support for any issues the team may experience during the deployment. Premier Support can also help review the current Server installation and validate whether it's ready for a move to Data Center.

Align the team on your Data Center goals

Data Center supports many features crucial to the management and operations of Jira, Confluence, Bitbucket, and Crowd at scale. It's important that these features, the associated goals of adopting these features, and the metrics showcasing the impact of meeting these goals are agreed upon and communicated to all stakeholders. During implementation, the team will evaluate a go/no-go decision based on these criteria. Deploying confidently to production requires that all stakeholders align on mutually agreed-upon business, functionality, and performance goals for the migration. Proper upfront alignment ensures a smoother installation, testing, and release process.

Review your current infrastructure

Benchmark and fine-tune your infrastructure, assess and upgrade governance, and review installed apps.

Benchmark your current infrastructure

Take a baseline measurement of your site's performance, and see whether it's still suitable to your organization's needs. Throughout testing, the team can measure the expected improvements resulting from migrating to a clustered deployment. Verify that all features and functionalities are working properly.

Even if your current infrastructure provides satisfactory performance to your users, benchmarking helps you quantify this. As your organization grows, so does your traffic and usage – those baseline measurements you took today can be used as you assess your infrastructure's suitability a year from now.

Optimize your application

Most scalable, multi-node cluster deployments allow an application to handle significantly more users, concurrently. While this is a significant gain (especially for growing businesses adding more users to their Atlassian applications), it's important to remember that clustering does not inherently improve the performance of each individual node. Performance issues not related to concurrency, especially those arising from sub-optimal configurations or usage in a single-node deployment, may persist or get worse in a cluster. 

For example, a single-node Jira instance with a large number of custom fields will likely experience performance degradation. Migrating this same Jira instance to a clustered Data Center will not improve performance, as the existing custom fields will continue to degrade performance. In this example, it is important to review custom field usage and eliminate them where not necessary to improve performance. To fully leverage Data Center's value, it's important to first completely review and optimize the existing Server installation to remove as many performance impediments as possible.

For example, in Jira, an increase of the following factors can impede application performance:

  • number of Jira issues
  • number of custom fields
  • number of email notifications
  • number of apps 1
  • number of workflow step executions
  • choice of server running the application

Review each of these factors to see where usage can be peeled back as much as possible in order to maximize performance.  Although you may spend 1-2 weeks to achieve the necessary performance optimizations, we've found that customers who don't do this early on tend to have a longer and more challenging deployment.

For help optimizing your application, see the following links:

Assess and update governance

How users interact with the application also affects application performance. For example, users that run frequent reports can place strain on the system causing performance degradation. These usage characteristics will need to be addressed before migrating. It may be necessary to place certain restrictions on scripts that make REST calls and other kinds of integrations. Specifically, scripts that execute many write operations can impede cluster performance as these write operations will sync across all nodes. The team will need to determine the correct balance between user functionality and performance that aligns with the organization's needs.

Review installed apps

The number of apps can impact your instance's performance, but you can help mitigate this by installing Data Center approved apps. Data Center approved apps undergo a rigorous technical review process (run by Atlassian). During this process, an app gets tested for performance, stability, and overall suitability for Data Center environments. For additional information on this process, see Guidelines for Data Center app development.

When reviewing your installed apps, check whether there are Data Center approved versions of them in Atlassian Marketplace. If not, check if there are alternatives available. See Evaluate apps for Data Center migration for more information.

Data Center approved apps are a class of Marketplace apps we launched in September 3, 2018. For more information, see this blog post.

Document current processes

After application tuning, document aspects of your single-node installation. This will help guide:

  • configuration options for the new deployment
  • influence process modifications motivated by the migration
  • identify whether issues observed after deployment are new or already existing

Some items to note are:

  • General system behavior benchmarks regarding operation, functionality, or performance of the Server application to identify if the Data Center deployment exhibits new or previously existing behavior
  • API access patterns for the application (heavy API usage may indicate a need to provision specific nodes to handle API traffic)
  • Backup processes and frequency
  • Reporting processes, frequency, and recipients
  • Monitoring tools and what is being measured
  • Scheduled maintenance routines
  • Disaster Recovery plans for the organization

Processes across different application instances will need to be documented, assessed, and appropriately consolidated into a single set of processes for the Data Center application. It is important to communicate these changes to each of the impacted teams continuously.

Evaluate technology decisions

Getting ahead of the following technology decisions and tasks will help the team more quickly design a production-ready cluster environment tailored to the organization's needs.

tip/resting Created with Sketch.

AWS and Azure templates

We provide fully supported templates for deploying clustered Data Center infrastructure on AWS and Azure. These templates provide a framework for deploying your infrastructure with recommended pre-set defaults. This framework helps speed up your deployment, as you don't have to build every piece of infrastructure from scratch. Rather, you can design your infrastructure around our templates and deploy it quickly on AWS or Azure.

For more information about using our templates, check out this blog post.


These are the key components of the multi-node cluster environment. Atlassian doesn't make specific recommendations on which vendors and options to use, but see We're here to help below for getting help with these decisions.

Load Balancer

The load balancer distributes requests from your users to the cluster nodes and provides high availability for your application. For more information about load balancers, see the following links:

Application nodes

Cluster nodes share the workload of incoming requests. All nodes, which must be in the same data center, are active and process requests. If a node fails, the load balancer will send requests to the remaining nodes in the cluster.

While some are guides for a single Server deployment, these links should give you a starting point as you consider what you need:

Shared database

Data Center applications generally support the same databases the Server application supports.

Bitbucket Data Center does not currently support MySQL.

When setting up your shared database, make sure that it allows at least the number of maximum connections across all nodes. For example, if you have 3 nodes that can each support a maximum of 50 connections, then your shared database must allow at least 150 connections. It's likely that you will need to configure additional connections for administrative or other purposes.

Shared file system

All clustered deployments require a shared file system, such as network attached storage via a file system protocol, such as NFS. All application nodes should have access to a shared directory in the same path. Examples of what the shared file system stores include plugins, shared caches, repositories, attachments, and avatars.

For more information on any of these components for each product, see the following links:

Cluster setup

It's a good idea to spend time evaluating, configuring, and optimizing your cluster configuration to ensure that it meets your organization's needs as best as possible. Here are a few examples of things that have come up when reviewing some of our customers' installations:

  • Evaluate if a cluster with fewer larger nodes or a cluster with more smaller nodes is a better fit for your environment.
  • Account for cascading failure when determining node size. This occurs when an instance fails and the remaining instances cannot handle the incoming load.
  • Consider traffic segmentation so that specified nodes exclusively handle specific kinds of traffic.
  • Investigate virtualization and automation tools such as Docker, Chef, and Puppet to better manage scaling the cluster.
  • Invest in robust monitoring tools such as New Relic, Splunk, and ELK.
  • Ensure existing monitoring tools are reconfigured to handle multi-node environments.

Implement your test & deployment process

Test your clustered deployment and launch your Data Center on production.

Test your clustered deployment

In order to confidently deploy your clustered deployment to production, the team should run through an iterative set of functional tests, integration tests, and performance tests. Team members should agree to a set of metrics to effectively evaluate a go/no go decision. The following is a general process we recommend to customers for a successful deployment. 


The timing for each step is an average we've seen across our customers who have successfully migrated to clustered infrastructure. 

  • Test: After migrating the application to a test environment, the team should run a collection of user acceptance tests, which verifies functionality, performance, and integrations relevant to the organization. Each test may span 1 to 2 weeks and ensure that a set of metrics are being met. This is an iterative process that should test a variety of characteristics to ensure that the application is production-ready. This is the most intensive part of the migration process and typically takes about 3 - 6 months to execute.
  • Refine: Results from the user acceptance tests will help direct the team how to optimize configurations in the application and harden processes governing application usage. It ensures that the organization's processes and application configurations are tightly coupled.
  • Document: The team should be documenting everything throughout the entire process and then use this time to sort and refine all documentation related to installation, configuration, network diagrams, architecture diagrams, lessons learned, bugs, resolutions, and anything else relevant to the application.

Launch your Data Center on production

  • Commit: Using the results of the testing and refinement, the team evaluates if the clustered deployment is ready for production. If not, iterate back to testing to identify shortcomings and gaps.
  • Execute: Organizations typically push to production over a weekend or some other time of low usage. Some customers opt for a "mock deploy" to test and verify their launch process. Ensure that notifications are sent to end users throughout this process. 
  • Support: It's critical that the team monitors the Data Center application after launch and checks for any functional or performance issues.

 We're here to help

We have a range of services and programs designed to help you choose and implement the right solution for your organization. Check our Enterprise services page for details about services included with your Data Center license, as well as our paid services.

Last modified on Sep 20, 2021

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.