What to Clean Up Before an Atlassian Server or Data Center to Cloud Migration

Every Atlassian migration plan starts with the same question — what moves? The more useful question, and the one that decides how long it takes, is what doesn't. A Server or Data Center instance that has been running for years is carrying configuration nobody remembers creating, for teams that no longer exist, wired to systems that were switched off.

You can move all of it. It will work. It will also cost you the effort of migrating things you were about to delete, and it will land you in Cloud with the same mess in a more expensive place.

Clean Up Before, Not After

The argument for cleaning up after the move is that it gets you live sooner. In practice it rarely happens — once the instance is live and people are working in it, the appetite for touching workflows disappears, and the cleanup becomes a backlog item nobody picks up.

Cleaning up first also shrinks the thing being tested. Every workflow, custom field and app you retire before the migration is one less item in the validation pass, and validation is where migration timelines actually go.

What Usually Needs Retiring

Custom fields

Custom fields accumulate faster than anything else and are the single biggest driver of a slow, confusing Cloud instance. Look for fields with no values in the last year, fields duplicated across projects because two teams each made their own, and fields attached to screens nobody uses.

The test is not "is this field used" but "would anyone notice if it were gone". Those are different questions and the second one is answerable.

Workflows and statuses

Most long-lived instances have workflows that differ from each other in ways nobody can explain. Before migrating, find the workflows that are genuinely distinct and the ones that are near-copies, and consolidate the copies. A status named slightly differently in three workflows is three statuses in Cloud.

Projects and users

• Archived-in-practice projects. Projects with no activity for a year are candidates for archiving rather than migrating. They stay readable and stop being your problem.
• Deactivated users. Inactive accounts still carry permissions, filter subscriptions and dashboard ownership. Resolve who owns their filters before they disappear.
• Group sprawl. Groups created for one project and never removed become permission decisions you have to re-make in Cloud.

Marketplace apps

Apps are where migrations stall, and the reason is rarely the app itself. It is that some apps have no Cloud equivalent, some have a Cloud version that works differently, and some hold data that does not migrate with the app. Inventory them early and put each in one of three buckets: has a Cloud path, has a replacement, or is being retired.

The apps that hurt are the ones a single team depends on and nobody else knows about. Ask.

What Not To Clean Up

Cleanup has a stopping point, and going past it delays the move for no gain.

• Historical issues. Old tickets are cheap to move and expensive to argue about. Move them.
• Anything a compliance or audit obligation covers. Retention rules do not pause for a migration.
• Configuration you would have to redesign. If fixing it properly is a project of its own, migrate it as-is and fix it in Cloud where you are not also managing a cutover.

The line sits where cleanup stops reducing migration effort and starts becoming a separate improvement programme wearing a migration badge.

A Sequence That Works

• Inventory first, decide second. Produce the list of fields, workflows, projects, groups and apps before anyone argues about what to keep. Arguments about unlisted things go nowhere.
• Retire what nobody claims. Publish the list, give people a window to object, and remove what draws no objection. Silence is a decision.
• Consolidate what is nearly identical — the near-duplicate workflows and fields.
• Resolve the app list last, because it is the one that may change what you migrate rather than just how much.

Each step shrinks what has to be validated after the cutover, which is the part that determines whether the migration feels controlled or feels like an outage.

Scope Is A Decision, Not A Discovery

The instinct on a migration is to move everything because deciding is harder than copying. But a scoped migration is not a compromise — it is the version where the destination is deliberately better than the origin, and it is the only version where the validation pass is finishable.

See how this played out in practice: a legacy Atlassian Server to Cloud migration for a public-sector organisation. If you are planning a move, our Cloud migration work starts with exactly this inventory. Once the scope is settled, moving the data is its own problem — issues, attachments, users and app data do not move as one thing.