“We can’t move to Cloud because of data residency.”
That may still be a valid answer. But when was it last checked?
I work across Data Center and Cloud, so I’m interested in the details behind that sentence. Which data? Which app? Which requirement? And does the limitation still apply to the environment we want to use?
Atlassian has added options worth reviewing. Some are available with restrictions. Others are still planned.
The old migration spreadsheet deserves another look. Sorry to whoever has to organise that meeting. 😅
Information checked: 29 October 2026. Availability and roadmap dates can change.
Start with the exact requirement
“Data must stay in Europe” needs more detail before we can assess it.
Does that mean stored Jira content, backups, Marketplace app data, or AI processing? These need separate checks.
Jira, Jira Service Management and Confluence already support residency for in-scope app data on Standard, Premium and Enterprise plans. This is an established capability, not a new announcement.
Start with the data residency documentation and compare the scope with your requirement. Check each Marketplace app separately too. A pinned Jira site does not settle every connected app’s residency.
Three developments worth reassessing
1. Backup residency
Atlassian Backup and Restore has supported data residency since 28 April 2026. New backups for pinned Jira, JSM and Confluence apps store their in-scope backup data in the app’s region.
Existing backups do not automatically relocate. Backup policies, post-operation reports and configuration metadata are outside that scope.
For a backup-related blocker, those details give you something concrete to review.
Source: Backup and Restore residency.
2. C5 Type 2 evidence
Atlassian has completed the BSI C5:2020 Type 2 assessment for Jira Cloud, Jira Service Management and Confluence Cloud. Customers can request the report through the Trust Center.
That gives security teams evidence to assess, including how controls operated over a defined period. The report still needs reviewing against your organisation’s requirements.
“Report available” is a useful update to a blocker. “Everything approved” needs your own assessment.
Source: C5 Type 2 announcement.
3. Customer-managed encryption keys
Atlassian’s current CMK offering is a paid Cloud Enterprise add-on for new cloud sites, covering selected data in supported apps.
The new-site restriction matters. You cannot currently enable this offering on an existing site, so check the target setup before planning the migration.
Source: CMK eligibility and limitations.
Available does not always mean it solves your migration
Loom is a good example.
You can choose Germany when provisioning a new Loom site. Existing workspaces cannot currently move between regions, and existing videos cannot be transferred into the new residency-enabled workspace.
That helps a new deployment. It leaves a gap for someone who needs to move an existing video library.
Source: Loom residency limitations.
Keep planned capabilities visible, but separate
Atlassian’s Team ’26 Europe recap announces an EU AI inference early access programme for Q1 2027, intended to cover prompts, context retrieval and model processing within EU boundaries.
That is worth following when your requirement includes AI processing. Keep it recorded as an announced EAP until you can assess the actual availability and scope.
Source: Team ’26 Europe recap.
A small template for the next review
For each blocker, record:
- Requirement: What exactly must be true?
- Scope: Which apps, data and operations does it cover?
- Current option: What capability exists, on which plan, with which restrictions?
- Remaining gap: What is still missing or untested?
- Evidence and decision: Which documentation or test supports the decision, and who approves it?
- Next review: Who owns the follow-up, and when?
For example, “Loom must support Germany” is too broad.
“Existing Loom videos must move to Germany” makes the remaining limitation clear. A new-site option alone does not meet that requirement.
I would start with three blockers from your last assessment. Recheck the sources, update the remaining gaps and involve the people who need to approve the decision.
Some blockers may now be ready for testing. Others will remain open. Either result makes the next migration discussion more useful.
