Once a team decides to leave Jira, this is usually the next question. Most migration guides either skip it or answer with a single suspiciously round number.
Why there’s no single answer
Complexity drives this more than headcount does. We’ve seen a 200-person team with a handful of clean projects move faster than a 20-person team carrying a decade of ScriptRunner automation and five Marketplace apps nobody remembers installing. What sets the timeline is the number of projects, how much custom logic is layered in, and how many third-party apps are involved.
Timeline by complexity
| Complexity Tier | What That Looks Like | Typical Timeline |
|---|---|---|
| Simple | Small team, few projects, minimal automation or add-ons | Days to about a week |
| Moderate | Multiple projects, a handful of apps, some custom workflow logic | One to three weeks |
| Complex | Many projects, heavy automation, portfolio/reporting apps, tight integrations | Several weeks to a couple of months |
Treat this as a starting point, not a quote. Your timeline depends on your specific instance.
We’ve watched a 15-person team take longer than a 150-person one, purely because of how much custom logic they’d built up over the years. Team size isn’t the variable worth planning around.
What actually adds time
Rebuilding automation that nobody documented in the first place is usually the biggest one. Close behind it is chasing down data trapped in a Marketplace app with no export path. And then there’s the team that skips the pilot, only to realize afterward it would have caught the problem before it reached everyone else. Skipping that step doesn’t save time, it just moves the surprise to a worse moment.
Same fix for all three: migrate one live project first, before you set a cutover date for everyone else. It feels slower at the start. It isn’t, once the whole thing’s done.
Questions we expect you’ll ask
Can we get an exact estimate for our team?
Reasonably close. The sizing calculator asks for details about your actual Atlassian instance and estimates cost and complexity from those. No signup, nothing sent to a server, about five minutes of your time.
Does migrating faster mean cutting corners?
Not if the speed comes from having less to untangle, rather than from skipping steps. Keep the dry-run and the parallel-run window even on a fast timeline. They’re what catch problems before your whole team hits them.
Do you help with complex migrations?
We do. Schedule a call and we’ll go through your setup (apps, automation, timeline) before you commit to anything.
Get a timeline built around your actual instance
Run the sizing calculator for a cost and complexity estimate, or read the full migration guide for the step-by-step process.