Data Center to Atlassian Government Cloud: A Technical Migration Checklist for Government Teams

Moving from Atlassian Data Center to Atlassian Government Cloud (AGC) is not just a platform move. It affects users, permissions, workflows, custom fields, apps, integrations, identity, testing and the final cutover.

For government teams, the strongest migrations start with a clear view of the current environment. Before deciding what to move, teams need to understand what they have, what is still needed and what may need to change before it reaches AGC.

1. Start With a Full View of Your Data Center Environment

Most Data Center environments grow over time.

Projects are added, workflows change, apps are installed and user groups evolve. Before migration planning begins, create a complete inventory of the current environment.

Review:

• Jira and Jira Service Management projects
• Confluence spaces
• Users and groups
• Permission schemes
• Custom fields
• Workflows and statuses
• Automation rules
• Marketplace apps
• Integrations
• Data volume and attachments

The goal is not just to list what exists. It is to understand what the organization still depends on.

Inactive projects, outdated spaces, unused fields and old configurations may not need to move.

2. Decide What Belongs in the Future AGC Environment

Once the environment is documented, separate active requirements from historical configuration.

Review which projects are still in use, which workflows support current operations, which fields still matter and what data should remain part of the future environment.

Migration should not automatically recreate every Data Center decision inside AGC.

It is a chance to carry forward what still supports the agency and leave behind what no longer does.

3. Assess Marketplace Apps Before They Hold Up the Migration

Marketplace apps can have a major impact on migration.

Not every Data Center app is available in AGC and some apps may support important workflow, reporting, automation or integration functions.

For each app, ask:

• Is it still needed?
• Which projects depend on it?
• Is it available in AGC?
• Does its data need to migrate?
• Does it affect workflows or custom fields?
• What happens if it cannot move?

This review should happen before the target environment is finalized.

4. Clean Up Users, Groups, and Access Before the Move

Identity and access should be reviewed before data moves.

Long-running Data Center environments may contain inactive accounts, old group memberships, contractor access or admin permissions that no longer match current responsibilities.

Review:

• Active users
• Email addresses
• Group memberships
• Application access
• Project permissions
• Confluence space permissions
• Administrative roles

The goal is to make sure access in AGC reflects how the agency operates now.

5. Review Custom Fields and Workflows Before You Carry Them Forward

Custom fields and workflows are often where Data Center complexity becomes most visible.

Over time, agencies may accumulate duplicate fields, workflow variants, unused statuses and screens that no longer support current work.

Before migration, review:

• Custom fields
• Field contexts
• Screens
• Work types
• Workflow schemes
• Statuses
• Conditions and validators

Where possible, remove duplication and retire configurations that no longer serve an active purpose.

6. Map Integrations and External Dependencies End to End

Atlassian rarely works alone.

Government environments may connect Jira, JSM and Confluence with identity platforms, reporting tools, monitoring systems, internal applications, development tools or asset systems.

For each integration, document:

• Connected system
• Data exchanged
• Authentication method
• API dependencies
• Network requirements
• Integration owner
• Business impact if it fails

Do not only test whether systems connect. Test whether the full business process still works.

7. Design Identity and Access Before Production Migration

Identity should be treated as a core migration workstream.

Review:

• Identity provider configuration
• SAML SSO
• User provisioning
• Domain requirements
• Group structure
• Admin roles
• Access policies
• Joiner and leaver processes

If users cannot reach the right projects, spaces or service portals after cutover, the migration is not operationally complete.

8. Test the Migration the Way Users Will Experience It

Testing should go beyond checking whether data is visible in AGC.

Test:

• Projects
• Confluence spaces
• Attachments
• Custom fields
• Workflows
• Permissions
• JSM portals
• Automation
• Apps
• Integrations
• SSO
• Notifications
• Reports

Business users should also be involved.

An administrator may confirm that a workflow runs, while a daily user may notice a missing approval, notification or integration step.

9. Build the Cutover Plan Before Migration Day

Production migration needs a detailed runbook.

The team should know:

Who is doing what, when it happens and how success will be validated.

The cutover plan should include:

• Change freeze timing
• Final backups
• Source checks
• Migration sequence
• Technical owners
• User communications
• Validation steps
• Escalation contacts
• Contingency decisions
• Post-migration support

Some organizations may use a single cutover, while others may need a phased approach.

10. Validate the Environment After Go-Live

Migration is not complete when the data transfer finishes.

After cutover, validate:

• User access
• Groups and permissions
• Projects and spaces
• Service portals
• Workflows
• Apps
• Integrations
• Automation
• Reports
• Critical business processes

A defined post-migration support period also gives users a clear place to report issues while technical teams monitor the environment.

From Migration Checklist to Long-Term AGC Operations

A Data Center-to-AGC migration should be treated as a technical program, not a copy exercise.

A practical flow looks like this:

Assess → Clean → Map → Design → Test → Cut Over → Validate

Each stage prepares the team for the next and helps reduce unnecessary complexity before AGC becomes the new operating environment.

Why Clovity Brings a Different Perspective to AGC Migration

Clovity brings direct experience from the earliest stages of Atlassian Government Cloud adoption.

Clovity was the first Atlassian partner to deploy Atlassian Government Cloud, giving our team hands-on experience with the technical, security, migration and operational considerations involved in a real public sector AGC implementation.

That experience is backed by broader recognition across the Atlassian ecosystem. Clovity was named Atlassian Partner of the Year 2026 – Government Americas, reflecting our work with government organizations across cloud migration, service management, platform modernization and Atlassian adoption.

For government teams planning a move from Data Center to AGC, Clovity can support:

• AGC readiness assessments
• Data Center environment reviews
• App and dependency analysis
• Identity and access planning
• Migration architecture
• Migration execution
• Testing and validation
• Cutover planning
• Post-migration governance and support

The goal is not simply to move the existing environment into Government Cloud.

It is to help agencies build an AGC environment that is technically sound, easier to manage and aligned with how teams need to work after migration.

🌐 Visit www.clovity.com to get started today