Insights / News
DTA cloud guidance: what it means for Atlassian
Senzo Team /
Short answer
The Digital Transformation Agency has released whole-of-government cloud computing guidance for agencies implementing the federal cloud computing policy that took effect on 1 July. For anyone running Atlassian in government, the DTA cloud computing guidance moves the question from "are we allowed to use cloud" to "can we show why, at what cost, and with what dependency". That is a governance and documentation exercise, not a configuration one.
What happened
The DTA published guidance to help agencies make decisions across the cloud lifecycle and to get past common challenges, manage risk and build capability. It covers cloud strategy development; balancing contemporary cloud technology with legacy system management; security, privacy and operational resilience; optimising AI and cloud service consumption; procurement, cost and provider dependency management; and building cloud service management skills. The DTA's acting deputy CEO of strategy, planning and performance, Ramsey Beydoun, said getting cloud right means looking beyond the technology to choices that support better services, stronger resilience and long-term value. The guidance frames migration and legacy systems as one decision rather than a standalone move, and it points agencies at FinOps practices to connect cloud consumption with business value, including for AI-enabled services where expenditure varies significantly with usage.
Why it matters for an enterprise running Atlassian
Most government agencies we work with are not debating whether Atlassian belongs in cloud. That decision is largely made. What the guidance changes is the standard of evidence around it.
Three things follow.
Platform decisions now need a written rationale. If Jira, Confluence and Jira Service Management sit on Atlassian Cloud, someone may ask why, what was retired to get there, and what remains on Server or Data Center and why. The guidance's insistence on looking at migration and legacy together means "we moved the easy things" is a weaker answer than it used to be. A platform consolidation plan that names what stays, what goes and on what basis is the artefact that survives scrutiny.
Cost becomes a governance topic, not a finance clean-up. FinOps language in whole-of-government guidance raises the expectation that cloud consumption is actively managed against value. For Atlassian that means user tier and edition, how many products are actually in use, Marketplace apps that accumulated over years, and now AI consumption through Rovo. Agencies that cannot describe their Atlassian consumption pattern will find that gap visible.
Provider dependency gets named. Procurement and provider dependency management are explicitly in scope. Atlassian is a single vendor for a large part of your delivery tooling, and the guidance invites a documented position on that: what you would do if terms, pricing or product direction changed, and how your data and configuration would move. That is a reasonable question to answer before it is asked formally.
None of this is about whether Atlassian Cloud is the right platform. It is about whether the decision is documented well enough to defend, which is the same thesis we apply to every platform decision: planning and governance decide the outcome, not configuration.
What to do about it
- Write the platform position down. One or two pages: what runs on Atlassian Cloud, what remains on Data Center, the basis for each, and the sequence for the remainder. Keep it current.
- Map your legacy tail honestly. Identify the Jira and Confluence instances, apps and integrations still outside cloud, and decide per item: migrate, replace, or retire with a date.
- Establish consumption visibility. A monthly view of users by product, active versus licensed, app spend and AI usage. You do not need a FinOps function to start; you need the numbers in one place.
- Put a boundary around Rovo. Pilot with named teams, define what data assistants can reach, and review usage before widening. A person stays accountable for anything the assistant produces.
- Document the exit position. Where your configuration, attachments and history live, how they would be exported, and who owns that answer. This is a short document, not a project.
- Check your security and resilience evidence against the guidance's categories. Atlassian Guard, data residency, access controls and incident processes should map to what the DTA asks agencies to demonstrate.
If you want a second pair of eyes on the platform position before it goes upward, our Atlassian services cover advisory and governance work of exactly this shape, and our Atlassian FAQs answer the common questions that come up first.
Where it does not apply, or what to be careful of
The guidance is written for agencies implementing the federal cloud computing policy. It is guidance, not a technical standard, and it does not prescribe how to run Atlassian. Your agency's own cloud policy, your security classification and your records obligations still decide the detail.
Two cautions.
First, do not turn this into a documentation project that consumes the team. The value is in decisions being made and recorded, not in a binder. A short, maintained position beats a comprehensive one written once.
Second, Data Center is still the right answer for some workloads, particularly where a system is close to retirement or where a specific control cannot yet be met in cloud. The guidance acknowledges that some approaches need to be altered to fit specific situations. Say so plainly and with a reason, rather than migrating something you will retire in eighteen months to look consistent.
Takeaway
The DTA guidance does not change what Atlassian Cloud can do. It changes what government agencies should be able to explain about it: why the platform is where it is, what it costs, what still sits outside it, and what happens if the provider relationship changes. Those are governance questions, and they are answerable in a few well-kept documents. If your agency is heading into a cloud review or a platform consolidation, start with our Atlassian services and about Senzo to see how we work; scope follows an advisory conversation.
Frequently asked questions
Does the DTA cloud computing guidance apply to Atlassian Cloud?
The guidance is written for agencies implementing the federal cloud computing policy, and Atlassian Cloud is a cloud service, so it sits in scope. How directly it applies depends on your agency's own cloud policy and how you classify the platform: productivity tool, service management system, or both.
Do we need to redo our Atlassian Cloud migration because of this?
Probably not. The guidance is about decision-making across the cloud lifecycle, not a technical standard. What it does change is what you should be able to show: a documented strategy, a legacy systems position, cost and consumption visibility, and a view on provider dependency.
What does FinOps mean for Jira and Confluence licensing?
It means connecting consumption to value. For Atlassian that is user tier and edition, the number of products on the platform, Marketplace apps and AI consumption, all reviewed against what teams actually use. The guidance raises the expectation that this review happens, not the method.
How should we handle AI cost on Rovo?
The DTA notes that AI expenditure varies significantly with usage and that understanding consumption patterns early supports controls. Treat Rovo adoption as a governed rollout with usage visibility from the start, rather than switching it on broadly and reconciling later.
Does this guidance mean we must move everything to cloud?
No. The guidance explicitly looks at migration and legacy systems together and acknowledges some approaches will need to be altered to fit specific situations. The point is deliberate, documented decisions about existing systems, not a blanket move.