Atlassian Data Center to Cloud: the Australian migration guide

Atlassian Data Center products reach end of life on 28 March 2029 (Pacific time), which is the evening of 29 March in Sydney. From then, Jira, Jira Service Management, Confluence, Bamboo and Crowd Data Center subscriptions expire and the products become read-only. For most Australian organisations, the practical deadline is earlier. Existing customers can’t add users or buy new Data Center apps after 30 March 2028, and Atlassian’s Cloud Enterprise discount runs only until June 2027. So the realistic window to plan, test and migrate is 2026 to 2027.

This guide covers what is ending and when, and whether your data can stay in Australia. It sets out what APRA-regulated and Privacy Act-bound organisations need to check, what the migration tools will and won’t move, and how to sequence the work. It replaces our earlier Server-to-Cloud guides, which were written before Atlassian announced the Data Center end of life in September 2025.

What exactly is ending, and when?

Atlassian has set three milestones on its Data Center end-of-life page. Atlassian quotes Pacific time (23:59 PST). Sydney is 18 to 19 hours ahead, so each deadline falls on the following day here.

The products in scope are Jira Software, Jira Service Management, Confluence, Bamboo and Crowd Data Center, plus the Data Center mobile apps and the Marketplace apps built for them. Atlassian says it will offer extended maintenance after 28 March 2029 “by exception” for certain customers, arranged through your Atlassian account executive. Treat that as a fallback to negotiate, not a plan.

If you are still on Atlassian Server, you have been out of support since February 2024. Moving off Server is overdue, and the rest of this guide applies to you as well.

Does this affect Bitbucket or Jira Align?

Not in the same way. Atlassian’s end-of-life page makes two exceptions:

• Bitbucket Data Center is not reaching end of life. Existing customers get a Bitbucket Hybrid License, so they can use Bitbucket Data Center and Bitbucket Cloud together. If your source code has to stay on your own infrastructure, that option remains open.
• Jira Align Data Center continues beyond 2029.

Integrations are the catch. Bitbucket Data Center usually talks to Jira, and Jira Align usually syncs with Jira. Once Jira moves to Cloud, those connections cross from your network to Atlassian’s, so they need new firewall rules, authentication and testing. Put them in scope early.

Can our data stay in Australia?

Yes, for most of it. Atlassian Cloud offers data residency with an Australia location in the AWS Sydney region. You can pin Jira, Jira Service Management, Jira Product Discovery, Confluence and Loom data to Australia on the Standard, Premium and Enterprise plans.

The detail that matters is what is in scope. Issues, pages, attachments, comments, search data, configuration and notifications can be pinned. These categories can’t be pinned:

• User account information. It sits in a central identity service with globally distributed replicas.
• AI data. Plan for this if you intend to switch on Rovo or other Atlassian AI features.
• Connected DevOps data and app analytics.

Marketplace apps are a separate question. Whether an app’s data stays in Australia depends on how its vendor hosts it, so check each app you plan to keep.

Moving an existing cloud site’s data into the Australian location also involves downtime of up to 24 hours, and search can be degraded for up to 3 days while it re-indexes. Pin the location before you migrate, not after.

For government and government-adjacent work, Atlassian states that Jira, Confluence and Jira Service Management Cloud have been assessed at IRAP PROTECTED. Its trust portal holds the assessment report and addendum letters, the latest dated May 2026. An IRAP assessment is an independent assessor’s findings against the ISM, not a certification, so your security team still has to read the report and accept the residual risks.

Atlassian Government Cloud is a US offering (FedRAMP Moderate) for US agencies. It is not an option for Australian agencies.

What do APRA-regulated and Privacy Act-bound organisations need to check?

Two regimes come up in almost every Australian migration business case: APRA’s CPS 230 and the Privacy Act’s cross-border rules.

APRA CPS 230

CPS 230 Operational Risk Management has applied since 1 July 2025. The deadline for bringing existing service agreements into line passed on 1 July 2026. For banks, insurers and super funds, an Atlassian Cloud subscription that supports a critical operation, such as Jira Service Management running your IT incident process, is likely to be a material service provider arrangement. That has three practical consequences:

• Atlassian, and any Marketplace vendors handling your data, go on your register of material service providers.
• You must notify APRA no later than 20 business days after entering into or materially changing the agreement.
• If the arrangement involves offshoring, notify APRA before you enter into it. Data residency in Sydney reduces the offshoring question for in-scope data, but user identity data and AI data can still sit offshore. Ask your risk team to decide this explicitly, rather than assume it.

Build these steps into the migration timeline. They are approvals on the critical path, not paperwork you can do afterwards.

Privacy Act APP 8 and APP 11

Jira Service Management portals often hold customer and employee personal information. Under the OAIC’s APP 8 guidelines, giving personal information to an overseas cloud provider can be a “use” rather than a “disclosure” if you keep effective control. That means three things:

• A binding contract limits the provider to storing and managing the information.
• The provider’s subcontractors are bound the same way.
• You keep the right to access, change, retrieve and delete the information.

If you meet that bar, APP 8 doesn’t apply, but your APP 11 security obligations still do. If you don’t, you are accountable under section 16C for what the overseas recipient does. Combined with Australian data residency for in-scope data, most organisations can get to a defensible position. Document the reasoning before go-live.

Planning AI features in Jira Service Management after the move? The Privacy Act’s new automated decision-making transparency rules start on 10 December 2026. We cover what they require in Automated decisions and the Privacy Act.

Which Atlassian Cloud option suits us?

There are now three realistic destinations for a Data Center customer, plus one stopgap.

Our Atlassian licensing team can model plan and tier options against your user counts and app list. That’s worth doing before you commit to a deployment option, because the app list often decides it.

What does Atlassian offer to soften the cost?

Atlassian lists four migration incentives on its end-of-life page:

1. Cloud Enterprise discount. Customers buying Cloud Enterprise by June 2027 may be eligible for a 10–20% discount on the first year.
2. Step-up credits. These are equal to the pro-rated value of unused Data Center maintenance, so you don’t pay twice for the overlap.
3. Dual licensing. Larger customers can run Data Center and Cloud side by side during the move without paying for both.
4. Extended cloud migration trials. They run for the remaining life of your Data Center subscription, not the standard 7 days. That gives you a free Cloud site for test migrations and user acceptance testing.

The June 2027 date is the one to plan around. To buy Cloud Enterprise by then, most organisations need a decision and a signed business case by early 2027. That means doing discovery in late 2026.

What won’t the migration assistant move for us?

Atlassian recommends its free migration assistants for Jira and Confluence. The Jira Cloud Migration Assistant is “the easiest and most reliable way” to move, provided you are on a supported Data Center version. CSV import is explicitly not recommended.

The assistant moves the core of Jira well: projects, issues, comments, attachments, workflows, permission schemes, Jira Service Management customers and Assets. Its documentation also lists what it leaves behind. These are the items that cause surprises in user acceptance testing:

• Dashboards. They are not migrated. Teams that run their week from a dashboard will notice on day one.
• Cross-project boards and filters. Filters shared through project permissions and filter subscriptions are also left behind.
• Issue rank. Backlog order is lost, so product owners need to re-rank.
• Webhooks. Every outbound integration that relied on a Data Center webhook needs rebuilding against Cloud.
• Custom fields from Marketplace apps. These need a vendor-supplied migration path or a manual approach.
• Passwords. Unless you have single sign-on, every user resets their password. Set up SSO with your identity provider before cutover.
• Classic plans in Advanced Roadmaps, plus their scenarios and saved views.

Marketplace apps are usually the longest pole. App data migrates only where the vendor provides an automated migration path. Some Data Center apps have no Cloud equivalent, and others have a Cloud version with different features. Audit every installed app and classify it: keep, replace with a native Cloud feature, replace with another app, or retire. Usage data from your instance will show which apps nobody opens. Retire those first.

How long does a migration take, and what are the phases?

On our Atlassian Cloud migration page, we say a standard Server or Data Center to Cloud migration takes 4–12 weeks. Large or multi-instance estates take several months. The spread comes from apps, integrations, customisations and the approvals described above, not from the volume of data.

The sequence that holds up in practice has six phases:

1. Discover. Inventory users, projects, spaces, apps, integrations, custom fields, automation rules and scripts. Run the migration assistant’s pre-migration checks and identify inactive projects to archive rather than move.
2. Decide. Choose the plan and deployment option, the data residency location and the identity approach (SSO and user provisioning). Decide on the fate of each app. Start your CPS 230 and privacy assessments here, not at the end.
3. Clean up. Merge duplicate custom fields, retire unused workflows and schemes, and archive dead projects. Every object you don’t migrate is one you don’t have to test.
4. Test migrate. Run at least one full test migration into a Cloud trial site. Time it and test it with real users from each team. Then rebuild the items the assistant doesn’t move: dashboards, webhooks and app-specific configuration.
5. Cut over. Freeze changes, run the production migration, validate counts and permissions, switch integrations and redirect users. Cutover is commonly scheduled over a weekend, and large estates can migrate in waves by team or product.
6. Hypercare and optimise. Plan 2–4 weeks of close support for users and fix permission gaps as they surface. Then start using what Cloud adds, such as native automation, Atlassian Analytics and AI features, once governance is in place.

Integrations deserve their own workstream. Jira and Confluence rarely stand alone: they connect to Salesforce, Microsoft 365 and Teams, identity providers, CI/CD pipelines and finance systems. Our Atlassian integration practice treats a migration as the moment to replace brittle point-to-point scripts with supported Cloud connectors. For background, see how to integrate Atlassian with your tech stack.

When should we start?

Work backwards from the dates that bite, not from March 2029.

There is also a capacity argument. Every Atlassian Data Center customer worldwide faces the same dates. Migration partners and Atlassian’s own migration support will be busiest in 2028, when fixed-date projects and late starters collide. Moving in 2027 gets you better people and less risk.

Are we ready? A 12-point readiness check

Use this to judge whether you can start test migrations or still have groundwork to do. If you answer “no” or “don’t know” to more than 4 of the 12, start with discovery.

1. Are all Jira and Confluence Data Center instances on a version the migration assistants support?
2. Do you have a current list of every installed Marketplace app, with active usage and an owner for each?
3. Have you checked each app vendor’s Cloud migration path and Cloud data residency position?
4. Do you know which integrations connect to Jira and Confluence, and who owns each one?
5. Is single sign-on in place, or planned, with your identity provider for Atlassian Cloud?
6. Have you decided between Standard, Premium, Enterprise and Isolated Cloud, and documented why?
7. Has your risk team assessed whether the arrangement is a material service provider under CPS 230, if you are APRA-regulated?
8. Has your privacy team documented the APP 8 position, including out-of-scope data such as user accounts and AI data?
9. Have inactive projects and spaces been archived, and duplicate custom fields merged?
10. Are dashboards, filters and webhooks inventoried for rebuild, since the assistant won’t move them?
11. Is there a named business owner for user acceptance testing in each major team?
12. Do you know your Data Center renewal date, and how step-up credits and dual licensing apply to it?

Frequently asked questions

Will our Data Center instance stop working on 28 March 2029?

It becomes read-only, according to Atlassian. You will be able to view data but not create or edit work. Support and critical security fixes also stop on that date, unless you have negotiated extended maintenance by exception.

Can we still buy more Data Center users before 2028?

Yes. Existing customers can buy new subscriptions, apps and expansions until 30 March 2028 (Pacific time). After that, your tier is fixed until end of life.

Is Atlassian Cloud approved for Australian government work?

Jira, Confluence and Jira Service Management Cloud have been assessed at IRAP PROTECTED, and the reports are available through Atlassian’s trust portal. Each agency still makes its own risk decision based on that report.

Do we have to move everything at once?

No. The migration assistants support phased migrations by project or space, and dual licensing lets larger customers run both platforms during the transition. Phasing reduces cutover risk but extends the period in which integrations must work across both.

Plan your migration with Great Minds

Great Minds is an Atlassian partner based in Sydney. We deliver Data Center to Cloud migrations, licensing and managed support as part of our Atlassian System of Work practice. See how we consolidated go-to-market work for a global appliance manufacturer onto Jira and Confluence. For service desk teams, our Jira Service Management guide covers the basics.

If you want a clear view of your apps, integrations, compliance steps and timeline before the June 2027 incentive closes, talk to us about a migration readiness assessment.