Enterprise Jira Migration Crisis

The scenario is the kind of thing that lives in every enterprise's awkward middle drawer: a Jira instance with eight years of accreted custom fields, four orgs that each interpret "priority" differently, and a leadership mandate to move to Linear by end of quarter. The migration is three months in. It is not going well.

This is a walkthrough of using an AI-assisted workflow to recover it — not a recipe, and not a sales pitch for any particular tool. The methodology is what travels.

Problem

• 4 business units, ~1,800 active users, ~140,000 open issues.
• ~60 custom fields, ~30 of which are actually used; nobody can definitively say which 30.
• Three failed migration attempts. Two ended in rollback. One ended in a hybrid state that's still running.
• Six weeks until the executive deadline.
• The team has a competent migration plan in a 40-page Confluence doc. Nobody has read all 40 pages.

Traditional workflow

1. Two senior PMs spend a week interviewing field-by-field owners. Half don't reply.
2. The migration engineer hand-writes a field-mapping spreadsheet, mostly from memory.
3. A junior team member runs the import in a sandbox. It takes 18 hours. Half the issues fail validation. Nobody knows why.
4. The team triages failures one at a time. Patterns emerge after three days.
5. The exec deadline slips. The CTO writes a memo. Morale is bad.

Total elapsed: 4–6 weeks. Cost: roughly one engineer-quarter. Outcome: probably still slips.

AI-native workflow

The shape changes when the agent does two things humans can't do at scale: read the entire Confluence doc plus every related ticket, and pattern-match across 140,000 issues without getting bored.

1. Step 1IngestAll docs + 1% issue sample
2. Step 2ClusterFind the real field shape
3. Step 3Draft mapAgent proposes mapping
4. Step 4Dry runValidate against full set
5. Step 5NarrateStakeholder-ready summary

The work the human does:

• Hands the agent the full Confluence doc + a representative sample of issues.
• Asks for a clustered field mapping — not field-by-field, but "here are the five field families we actually have, and the seven we can deprecate."
• Reviews the cluster proposal with the four BU leads. Most of the calls take ten minutes because the agent has already framed the tradeoff.
• Asks the agent to draft the executive memo and the rollback plan and the customer-facing FAQ in one pass, all aligned to the same decisions.

Technical breakdown

The architecture is unremarkable on purpose:

• A long-context model (Claude Sonnet) handles the doc + sample synthesis.
• A second pass uses a tool-using agent to query the live Jira instance for distribution statistics on each field — not to migrate, just to count.
• The agent produces three artifacts: a YAML field-mapping spec, a Markdown rollout plan, and a one-page exec memo, all derived from the same source of truth.
• A human PM reviews the YAML. The migration engineer turns it into the actual import script.

Operational impact

• Field mapping done in 4 days instead of 4 weeks.
• Number of stakeholder meetings: down from ~30 to ~8. The remaining meetings are higher-signal because everyone read the agent-drafted brief in advance.
• Failed import rate in the dry run: down from ~50% to ~6%, mostly genuinely-broken historical data.
• Exec deadline: hit, with a week of slack.

The cost: roughly $40 in API calls and two days of senior PM time. The team that was burning out is now running the migration as a normal program.

Lessons learned

• The 1% sample is the unlock. A representative slice plus the full documentation gets you ~90% of the model's value at ~1% of the context cost.
• Decisions, then artifacts. Don't ask the agent to write the memo first. Ask it to surface the decisions, run them by humans, then generate the memo from the resolved decisions. Order matters.
• The migration engineer doesn't get replaced. They get promoted out of janitor work and into actual engineering — designing the import script, handling the genuinely-broken edge cases, owning the runbook.
• The Confluence doc was right the whole time. Nobody had read it, so nobody knew. This is the most common failure mode in enterprises: the answer exists, in writing, and no human has the bandwidth to find it.