
AGC Migration Assessment: Apps, Integrations, Identity, Data and Security Dependencies
Cloud migration decisions in government are rarely difficult because of the act of moving technology. The harder decision is determining which parts of the existing operating model should move with it.
That becomes particularly important with Atlassian Government Cloud. The environment has its own application availability, identity requirements, Marketplace considerations, integration requirements, and migration constraints. Atlassian currently supports Jira, Confluence, and Jira Service Management in Government Cloud, while Marketplace apps and integrations require additional evaluation.
For business and technology leaders, this makes an AGC migration assessment less about creating an inventory and more about identifying the dependencies that could change the migration strategy itself.
The objective is straightforward. Understand what needs to remain, what needs to change, and where the current environment does not translate cleanly into the future one.
Start With Business-Critical Capabilities
A migration assessment should not begin with a spreadsheet of applications.
It should begin with the services and capabilities the organization cannot afford to disrupt.
Jira, Jira Service Management, and Confluence may support very different business functions. Some projects may directly support mission operations. Some JSM workflows may underpin critical service delivery. Some Confluence spaces may contain operational knowledge that teams depend on every day.
That distinction should influence migration priorities.
Leaders should identify which capabilities are:
- Mission-critical and require continuity
- Operationally important but open to redesign
- Low-value and candidates for retirement
- Dependent on technology that may not be available in AGC
This approach gives the technical team a much more useful starting point. Instead of asking how to migrate everything, the organization first understands what it actually needs the future environment to deliver.
Challenge the Existing App Portfolio
One of the most important questions is whether the current application portfolio still makes sense in the target environment.
Government Cloud does not simply replicate the commercial Atlassian ecosystem. Atlassian identifies Jira, Confluence, and Jira Service Management as available applications, while Marketplace availability is more limited. Marketplace apps also require security assessment before installation.
That means every important app should have a clear business and technical disposition.
| Decision | Leadership Question |
|---|---|
| Retain | Is this capability still essential? |
| Replace | Can the requirement be met differently? |
| Redesign | Does the current implementation fit the target architecture? |
| Retire | Is the dependency still justified? |
This is particularly relevant for AGC apps. Atlassian states that supported Marketplace apps cannot simply be migrated automatically and recommends working with the Marketplace partner to determine whether a manual migration path exists.
The important leadership question is therefore not simply “Can this app move?” but “Is this capability important enough to solve for in the target environment?”
That distinction can prevent organizations from carrying unnecessary complexity into Government Cloud.
Look Beyond Atlassian Connections
The real migration complexity may sit outside Atlassian.
Jira and JSM environments frequently connect with identity platforms, development tools, enterprise applications, reporting systems, notification services, automation, and other operational systems. Those connections can determine whether a migration actually preserves business continuity.
Atlassian specifically calls out integration assessment as part of Government Cloud migration planning. Integrations are evaluated for FedRAMP compliance before being made available in Government Cloud, while external URLs configured for webhooks also require security consideration.
For leaders, the useful question is not how many integrations exist. Instead, they should ask which business processes depend on them.
A connection supporting a critical JSM workflow deserves far more attention than a legacy reporting integration that could be removed. This also creates an opportunity to simplify the architecture rather than reproduce every historical connection.
Treat Identity as an Operating Model
Identity is another area where migration planning needs to go beyond configuration.
Atlassian states that an identity provider is required for Government Cloud because single sign-on is the only login method. Atlassian also documents specific identity-provider requirements for AGC.
That makes identity migration relevant to more than the IAM team.
Leadership should understand how the identity model affects users, administrators, provisioning, access control, and service operations.
The assessment should establish whether the current model can support:
- Required SSO
- User provisioning and deprovisioning
- Group-based access
- Administrative controls
- Domain management
- External service access
The technical team can determine how those requirements will be implemented. Leadership needs to understand whether the change creates operational or adoption risk.
Examine Integration Dependencies Early
An integration that works today is not automatically an integration that belongs in the future architecture.
The assessment should establish the purpose, owner, authentication method, data flow, and business consequence of each critical connection. This becomes especially important when Government Cloud changes the way an integration can operate.
Atlassian's post-migration guidance, for example, identifies specific differences for integrations between Government Cloud and environments that remain outside it. Those differences can affect the architecture of connections that organizations previously considered routine.
The result should be a clear decision for every important dependency:
- Retain: The integration is required and can operate within the target architecture.
- Modify: The integration remains necessary but requires changes.
- Replace: Another integration method or solution is needed.
- Retire: The integration no longer provides sufficient business value.
That gives architecture teams something actionable rather than another integration inventory.
Assess Data by Business Function
Data volume is a poor indicator of migration risk.
A small amount of information can be operationally critical, while thousands of historical records may have little practical value.
The more useful question is whether the business function supported by that information will continue to work as expected.
This matters because Atlassian documents migration limitations and differences in data parity for Cloud-to-Government Cloud migrations. Certain entities, configurations, and features do not have identical migration treatment.
Leaders should therefore ask:
Which processes depend on data or functionality that will behave differently after migration?
That question can surface risks that a simple data-volume assessment would miss.
It also prevents teams from spending equal effort on information that has very different business value.
Separate Platform Security From App Risk
Government Cloud's FedRAMP Moderate authorization provides an important security foundation, but it should not be interpreted as eliminating organization-level assessment.
Atlassian describes AGC as operating under a shared responsibility model. Its developer documentation also outlines additional requirements around Government Cloud applications and Marketplace apps.
This distinction matters.
The platform's authorization addresses the controls within Atlassian's responsibility. Organizations still need to understand the security implications of the applications, integrations, permissions, identities, and external services they introduce.
Marketplace apps are a good example. Atlassian states that Marketplace apps do not themselves need to be FedRAMP Moderate authorized to operate in AGC, but customers must conduct a security assessment before installing them.
The assessment should therefore make ownership explicit:
What does Atlassian secure? What does the organization control? Which dependencies require additional review?
That clarity is more valuable than simply recording the environment's authorization status.
Don't Recreate Existing Architecture
The strongest reason to conduct an AGC migration assessment is not simply risk reduction.
It is the opportunity to make deliberate choices about the future environment. If an application no longer provides enough value, there may be little reason to carry it forward. If several integrations support an outdated process, migration may be the right point to simplify them.
If a heavily customized JSM workflow no longer reflects how teams operate, reproducing it exactly may create more technical debt. The objective should not be a perfect replica of the old environment.
It should be an environment that supports the organization's future operating model within the requirements of Government Cloud.
What Leaders Should Know Before Approval
Before approving migration execution, business and technology leaders should be able to answer five questions:
- Which capabilities cannot be disrupted?
- Which applications can actually support the future environment?
- Which integrations and identities create migration dependencies?
- Where do data or functionality limitations affect business processes?
- Which unresolved issues could change the migration plan?
If those answers are clear, the organization is in a much stronger position to move from assessment to execution.
The value of an AGC migration assessment is therefore not the inventory it produces.
It is the decisions it makes possible.
How Clovity Can Help
Clovity approaches Government Cloud migration from both the technology and operating-model perspective.
With expertise across Jira, Jira Service Management, Confluence, integrations, automation, identity dependencies, and Atlassian architecture, Clovity can help government organizations evaluate the dependencies that sit behind their current environment and determine how those dependencies should be handled in AGC.
Clovity has been named Atlassian Partner of the Year 2026 – Government Americas.
As an Atlassian Platinum Partner, Clovity can help organizations assess their application landscape, evaluate AGC apps, examine integration and identity dependencies, identify migration constraints, and define the target architecture before execution begins.
The objective is not to replicate everything that exists today.
It is to help leaders make informed decisions about what belongs in AGC, what needs to change, and what should not be carried forward.



