Why cleanup before migration matters
Atlassian's migration guidance is unusually direct here. It recommends cleaning up your instance before migration because carrying more data and complexity makes migration longer, harder, and noisier. That recommendation is broader than performance tuning. It applies directly to access structure and administrative clutter.
There are also some specific migration risks worth taking seriously:
- groups with identical names in Server or Data Center and Cloud can be merged
- group linking by name can cause permission escalation
- users who already have app access in Cloud may continue to have it after migration even if their Server status was disabled
- approving migrated group permissions can add active users to your bill
That is why a pre-migration cleanup checklist is not just good hygiene. It is blast-radius reduction.
The checklist
1. Review users before the move
Start with user inventory, not projects.
Check:
- inactive users
- leavers and contractors
- duplicate or suspicious user identities
- users who already exist in the Cloud destination
- non-human accounts that should not be treated like normal human cleanup candidates
Atlassian notes that if a user already has app access in Cloud, that access can continue after migration even if the user is disabled in the Server source. That single detail is enough reason to do user review deliberately before the move.
2. Review groups before the move
This is where many migration teams get surprised.
Atlassian explicitly warns about name-based group linking and the possibility of permission escalation during migration. So before you migrate, review:
- groups with names that already exist in Cloud
- groups nobody owns
- groups that still grant app access
- groups used in permission schemes or roles
- externally managed or synced groups that need coordination outside Jira
If you skip this, you are not just carrying clutter forward. You may be carrying confusing access consequences forward.
3. Review permissions and project roles
Do not leave shared permission structure for later if the migration is already exposing it.
Before the move, identify:
- shared permission schemes
- overly broad permissions that should not be normalized into the new environment
- project roles that no longer reflect real ownership
- places where groups and roles have become too tangled to review confidently
This is not about rebuilding the whole access model from scratch before migration. It is about reducing the biggest unknowns so you do not arrive in Cloud with the same ambiguity plus a new platform context.
4. Review old projects and containers
Atlassian's cleanup guidance recommends listing which projects you actually want to migrate and removing projects you do not need before migration. That advice is practical, not theoretical.
For old projects, decide:
- migrate as-is
- archive first
- leave behind
- split out for later review
The mistake is assuming every old project deserves a free ride into Cloud. Migration is a rare chance to stop paying operational attention to dead structure.
5. Document decisions before cutover
This is the least glamorous step and one of the most important.
Before cutover, capture:
- which groups were reviewed and why
- which users were held, removed, or deferred
- which permissions were left alone deliberately
- which projects were archived, excluded, or flagged for follow-up
- who approved the decisions
If you do not do this, the post-migration environment inherits not only the structure, but also the uncertainty around why it looks the way it does.
6. Use test migrations to expose unclear cleanup decisions
One of the practical advantages of test migrations is that they surface where your cleanup story is still too vague.
If the same questions keep reappearing in test runs, that is usually a signal that one of these areas is still weak:
- duplicate or conflicting user identity state
- unclear group ownership
- shared permission structure nobody has mapped cleanly
- too many "we will sort that out later" project decisions
Treat those recurring test-migration questions as cleanup findings, not just migration noise. They tell you where the current Jira environment still depends on institutional memory instead of explicit review.
What people often miss
Migration is a deadline, not a cleanup method
Some teams treat the migration date as the reason cleanup will somehow get clearer. It will not. A deadline creates pressure. It does not create a better review model.
Group-name collisions are not cosmetic
Because migration can link groups by name, naming issues can become permission issues. That makes group review a real preflight task, not just a nice-to-have.
Old users can still change the Cloud outcome
Existing Cloud access, migrated app access, and later permission approval decisions all interact. User cleanup is not separate from migration. It is part of it.
The move exposes both access risk and cost risk
Some teams think of migration cleanup only in security terms. Others think of it only in licensing terms. In practice, it is both. Stale users and stale groups create access ambiguity and spend ambiguity at the same time.
Documentation matters more after migration than before it
Before the move, the current admins often still remember the history. After the move, new context gets layered on top immediately. If the pre-migration cleanup decisions were never recorded properly, the destination environment starts life with unexplained structure and deferred arguments. That is one reason seemingly "minor" documentation work pays off disproportionately during post-migration stabilization.
A simple stop / go framework
| Area | Go if... | Stop if... |
|---|---|---|
| Users | obvious stale rows are reviewed and duplicates are understood | destination access state is still unclear |
| Groups | name conflicts and ownership are understood | groups may merge or escalate access unpredictably |
| Permissions and roles | shared structure is visible enough to explain | no one knows the blast radius of a change |
| Projects | you know what to migrate, archive, or leave behind | old projects are being migrated only because nobody reviewed them |
| Documentation | decisions are recorded | all context still lives in admin memory |
What can reasonably wait until after the move
Not every cleanup decision has to be completed before cutover. The point is not to create a perfect source environment. The point is to avoid migrating uncertainty you already know is dangerous.
Work that can often wait until after the move:
- lower-priority permission simplification once the biggest shared-scheme risks are understood
- cosmetic naming cleanup that has no access impact
- project tidying that does not change migration scope or access behavior
Work that usually should not wait:
- unclear user identity state
- group conflicts or name collisions
- major default-access confusion
- projects nobody can justify migrating
- access questions that could create post-migration permission surprises
This distinction matters because migration teams often fail in opposite directions. Some defer too much and carry avoidable mess into Cloud. Others over-clean under deadline and create unnecessary change risk. A better checklist separates true preflight blockers from work that is safe to defer deliberately.
Where focused tools fit
Migration cleanup usually splits into two hard lanes.
Lane 1: group and permission impact
If the blocker is proving whether a group can be changed, removed, or carried forward safely, use the Jira group cleanup use case and compare native Jira review vs Group Impact Audit for Jira. The product route in this repo is Group Impact Audit for Jira.
Lane 2: stale users and billable access
If the blocker is renewal pressure, dormant rows, or explaining which visible supported access paths are still keeping seats alive, use the Atlassian license renewal use case and compare spreadsheets vs License Guard, then review License Guard.
The important point is that migration cleanup is not one product-shaped problem. It is a route-choosing problem.
Next steps
- Read The Jira Cleanup Guide if the migration scope is still too broad.
- Read What to Review Before Deleting or Renaming a Jira Group for the highest-risk pre-change group lane.
- Read The Hidden Cost of Inactive Users in Jira and Atlassian Cloud if the migration pressure is exposing seat waste.
Cloud moves are expensive enough already. The goal of cleanup is not perfection. It is reducing the amount of uncertainty you choose to migrate.
FAQ
What should be cleaned before migrating Jira to Cloud?
Review users, groups, shared permissions, project roles, and old projects before the move. Those are the main areas where stale structure turns into migration friction or risk.
Do you need to review group membership before migration?
Yes. Atlassian warns that groups can link by name and that this can cause permission escalation, so group review is a real pre-migration task.
Should old projects be archived or deleted first?
That depends on retention and business need, but you should not migrate old projects automatically just because nobody reviewed them in time.
How do you document cleanup decisions for a migration?
Record what was reviewed, what changed, what was deferred, and who approved it before cutover so the Cloud environment does not inherit unexplained structure.