Atlassian Cloud migration FAQ

This FAQ answers the questions organisations ask most often when planning a move from a Server or Data Center instance to Atlassian Cloud. It is grouped from the basics — what cloud migration actually means — through to the practical detail of tiers, apps, cost and process. If your question is not here, the Ask-a-Question form below goes straight to a consultant.

The basics: cloud, SaaS and migration

What is cloud computing?

Cloud computing means accessing services — data storage, servers, software, databases — over the internet rather than running them on your own hardware. It lets organisations of any size reduce IT infrastructure costs, improve application performance, and gain the flexibility to handle unpredictable resource demands.

What is SaaS (Software as a Service)?

SaaS is a subset of cloud computing where the software is delivered directly by the vendor — hosted, configured and ready to use. Jira Software Cloud and Confluence Cloud are examples. By contrast, self-managed products such as Jira Data Center can run on cloud infrastructure but are not themselves SaaS applications, because you still manage them.

What is cloud migration?

Cloud migration is the process of transferring critical infrastructure, applications, IT processes and databases from legacy or on-premises systems into a cloud provider's virtual data centres.

What is a SaaS migration?

A SaaS migration moves existing legacy or on-premises systems — including data, configurations and integrations — into SaaS solutions. Because cloud platforms often use a different architecture, your data, configurations and integrations may need to be transformed to achieve an equivalent outcome. Migrating Jira Server to Jira Cloud, for example, can require changes to apps, automations, integrations and user directories.

Benefits, safety and challenges

What are the benefits of moving to the cloud?

The main benefits fall into five areas. Security: cloud providers maintain dynamic security systems that evolve with current threats, unlike a static on-site data centre. Agility and scalability: cloud services support collaborative, remote-friendly working and scale capacity as your requirements change. Disaster recovery: cloud offers backup and recovery options that were previously out of reach for smaller organisations, making mission-critical systems more resilient. Reduced hosting costs: there is no expensive physical infrastructure to maintain, turning capital costs into a predictable operational subscription. Saving resources: capacity scales with actual need, so you no longer pay for under-utilised servers.

There are many benefits of migrating to the cloud. We have listed the most notable ones here.

• Security: On-site data centres tend to have static security systems — the security does not change or evolve over time. Reputable cloud hosting services have teams devoted to staying up to date with IT security threats, and adjust their security systems accordingly.

• Agility and scalability: Cloud services allow teams to work collaboratively on projects, especially in a world that is rapidly moving towards remote being the norm. It also allows you to scale your capacity needs as your requirements grow or change.

• Disaster recovery: Cloud allows even the smallest of companies access to back-up and recovery options that simply would not have been possible in the past. Having your mission-critical systems and data stored virtually means they are much more resilient to the kind of issues that would be a disaster for data stored on-prem.

• Reduced hosting costs: Maintaining, upgrading and upscaling physical on-site data storage is a costly endeavor. Your cloud hosting company manages the servers, often on a subscription basis which changes a capital cost into an operational cost.

• Saving resources: Your cloud capacity changes as your need increases. You do not need to have vast, mostly empty servers set up for the future. The cost of running and maintaining those servers will continue, whether you use them to capacity or not.

Is the cloud safe?

Given the recent rise in popularity of cloud services, due to the pandemic, many IT security companies have focused R&D on improving the already impressive cloud security offerings. In many ways, cloud security is better and more flexible than on-prem security. For example, Atlassian spends a great deal of effort to make their SaaS services robust and safe. You can see more detail in their Trust Center.

It is also a fact of life that not every IT professional in your company will trust the cloud. This may lead to more training and consultation for people who are unsure of the change, in order to reassure them of its worth.

Cloud security has improved substantially, particularly as adoption has accelerated in recent years, and it often surpasses on-premises security in both flexibility and robustness. Atlassian invests heavily in SaaS security; the detail is published in their Trust Center.

What challenges are involved in moving to the cloud?

Four are worth planning for. Data loss: during migration, data can be vulnerable to unauthorised access or loss, so proper security protocols are essential. Compatibility: moving from Server or Data Center to Cloud can surface addon and configuration compatibility issues. Resource management: staff unfamiliar with cloud may need training and consultation, and occasionally new IT roles. Downtime: migration usually involves some downtime, though an experienced partner minimises it through proper planning and backups.

Plan for downtime, do not pretend there is none Any honest migration plan accounts for a cutover window. The goal is to make it short, predictable and well-communicated — backed by tested backups and a clear rollback position — not to claim it will never happen.

Moving from Atlassian Server

We already use Atlassian Server — why should we move to Cloud?

Atlassian has ended Server sales and support, which leaves Server customers with two paths forward: Data Center or Cloud. If you are still on Server, you are running unsupported software, and the decision is no longer whether to move but where to.

The important dates for Server customers were (all in Pacific Time):

• 2 February 2021 — end of new licence sales.
• 2 February 2021 — end of Server product feature development.
• 2 February 2021 — pricing changes.
• 2 February 2021 — end of sale for apps now included in Data Center.
• 1 May 2021 — end of new app submissions.
• 15 February 2022 — end of tier upgrades and downgrades.
• 15 February 2023 — end of new app sales.
• 15 February 2024 — end of support.

Which Atlassian Cloud tier is right for us?

Atlassian Cloud is used by more than 80% of Fortune 500 companies, but it is not only for large enterprises. It serves organisations from fewer than ten users (the Free tier) up to tens of thousands (Enterprise), with Standard and Premium in between. The right tier depends on your user count, the support level you need, storage requirements and uptime guarantees. As an accredited Atlassian Solution Partner, BDQ can help you weigh these against a feature comparison and land on the best fit. The table below gives an idea of the differences between tiers.

Cost, apps and change

Is there a cost benefit to moving to Atlassian Cloud?

A Forrester Consulting study commissioned by Atlassian found that a composite company using Jira Software and Confluence on Cloud achieved a 155% return on investment, with payback inside six months. As with any commissioned study, treat the headline figure as indicative rather than a guarantee for your specific situation — but the direction of travel is clear once you account for removed hosting and maintenance overhead.

Can we migrate our Atlassian addons and apps to Cloud?

Where a Cloud version of an app exists, it often differs from the Data Center or Server version — sometimes only cosmetically, sometimes functionally. Those differences do not necessarily mean lower quality. Atlassian Cloud products themselves differ from their Server and Data Center counterparts, and in some cases native Cloud functionality removes the need for an app you previously relied on. A Solution Partner such as BDQ can map your current apps to what is available in Cloud and flag anything that needs replacing.

Cloud versions of your apps, if they are available at all, will often differ from their Data Center or Server versions. These differences may merely be cosmetic, but may also have more functional variations. But these differences do not necessarily make them better or worse, just different.

In fact, the Atlassian products themselves have variations from Data Center or Server to Cloud versions, meaning you may no longer need those same apps. If you are migrating with an Atlassian Solution Partner like BDQ, we can give you more details on what comes with the Cloud versions and what apps you may need for them to feel familiar and meet your requirements. For more information on the role apps play in a migration, read our blog post.

How different will Cloud be? Will our staff need training?

Cloud differs from Server and Data Center in functionality, included features and how some workflows are executed. Many organisations treat this as an opportunity to streamline rather than a problem to manage. A migration partner can discuss training, adoption and reimplementation strategies — reimplementing alongside the migration is often the best way to simplify workflows and avoid carrying unnecessary complexity into the new instance.

The migration process

Does BDQ have a migration process?

Yes. As an Atlassian Solution Partner with extensive cloud migration experience across organisations of every size, BDQ follows a structured process designed to minimise risk and downtime without rushing.

"If you are migrating to Atlassian Cloud, it is cheaper and quicker to use an experienced Atlassian Solution Partner like BDQ than to do it internally."

Tom Cahalan, Managing Director, Aurora Commerce

The BDQ Cloud migration process

1. Discovery and scope. Understand the current estate, the goals of the move, and what success looks like.
2. Analysis. Assess apps, configurations, integrations and data quality, and identify anything that needs transformation or replacement.
3. Data transfer planning. Plan how data moves across, including any cleanup or restructuring required.
4. Migration process development. Build and document the repeatable migration runbook.
5. Test migrations. Run trial migrations to validate the process and surface issues early, well before go-live.
6. User acceptance testing. Have real users confirm the migrated environment behaves as expected.
7. Go-live. Execute the planned cutover with a short, well-communicated window and a clear rollback position.

How do I prepare for a Cloud migration?

Over time, instances accumulate unused apps, obsolete projects, duplicate schemas, inactive users and over-complicated workflows. A migration is the ideal moment to clear these out before transferring anything, which reduces complexity, risk and cost. BDQ can audit your instance as part of discovery — reporting on active projects, workflows and custom fields, user and group usage, and configuration that is no longer earning its place.

As with any system or instance, over time they can become cluttered, sprawling and overly-complicated to use. Unused or duplicate apps, obsolete projects, schemas and workflows, and inactive users can all contribute to a slow, bloated and dysfunctional system. Whether performing your migration in-house or engaging a Cloud Migration Partner, preparing for a Cloud Migration is a perfect opportunity to clean up your instance by removing the previously mentioned issues. You do not want to bring them with you to your new, pristine Cloud instance — it will not only slow down the migration but also introduce unnecessary risk and cost.

You can also download and run our free Atlassian Marketplace app — BDQ Cloud Migration Analyst for Jira Cloud. Get useful statistics and duplicate email addresses before doing a migration to Jira Cloud, and easily export them to CSV. You can then use the data in-house or send it to us so that we can provide a more accurate idea of the scale of your migration.

What are the concerns when merging multiple instances?

Merging multiple instances increases complexity exponentially compared with a single-instance migration. Each instance brings its own apps, workflows, schemas, current and obsolete projects, and inactive users — instead of straightening out one tangle, there is one for every instance that needs to migrate. Even so, once the instances are merged you will often find that the newly merged instance can run as smoothly as a single instance. With careful planning and certified Atlassian expertise it can be completed without too many issues — but expect it to take longer and cost more than a single-instance move.

Do I need an Atlassian Solution Partner to migrate?

Strictly, no — an internal IT team can perform a migration independently. The honest comparison is replacing an engine: it is possible to learn and do it yourself, but a Solution Partner brings years of experience, specialist skills and purpose-built tools that make a successful outcome far more likely, while freeing your internal team to keep the business running.

Short answer — no. Using an Atlassian Solution Partner is not required in any way. You are free to perform the migration with your own internal IT team, should you desire. However, just because you can, does not mean you should.

Think of it like this — you know you have a problem with your car's engine and need to swap the engine out, but you have very little or no mechanical knowledge to draw on. You can change a tyre or check the oil but you have never checked an engine over before. Sure, you could learn, you could use online tutorials and videos to help you, you could save money by investing a huge amount of time and resources learning to perform a process that you will likely never use again. Or — you could pay a mechanic to do it for you. Someone with years of experience, all the necessary skills and tools to draw on, someone who does engine changes all the time. Yes, it is going to involve a substantial investment, but at least you know that when you turn the key, your new engine will start first time.

If you would like to talk through your specific situation, the Ask-a-Question form below goes straight to a consultant. For wider context, see Atlassian insights: from implementation to adoption.