Do the estate audit before the migration plan

What people say about it

Read a few migration threads on the Atlassian forums or r/jira and you notice nobody complains about the move itself. They complain about what they found when they looked: hundreds of custom fields nobody owns, workflows with ten years of post functions stacked up, ScriptRunner scripts holding half the business logic. One admin inherited 932 custom fields after a spin-out and needed almost none of them.

A consultant who said he had done about fifty of these put the technical move at 30 percent of the work. The rest is cleanup and decisions. That matches what we have seen.

Where the time goes

The assessment. Clients remember the spreadsheet a partner gave them: every app, workflow and script with a traffic light for effort. It turned an unknown into a plan. Producing it is slow, repetitive, and done by senior people, so it competes with billable work.

What we would build

A crawler with read-only access pulls the configuration. A classifier tags every item as duplicate, unused, migratable or blocker, and records the rule it used and how sure it was. A consultant reviews the list and accepts, edits or rejects each line. Accepted lines become a phased backlog in Jira Cloud and a report in Confluence.

Fields and apps first, because they are clean exports and because apps are where timelines break. An app that exists on Cloud but lacks one feature a team uses every day is the finding that adds two months. You only catch it early with usage data next to the app list.

Nothing writes to Cloud until a person approves. Duplicate fields the migration assistant creates get flagged, not deleted, because somewhere a dashboard depends on one. It would not estimate effort, read inside scripts, or set the phase order. Those come after it has been checked against a couple of finished migrations.