For years, many of us treated migration as a lift-and-shift exercise—moving Jira and Confluence from on-premises Atlassian Data Center (or Server) platforms to Atlassian Cloud. More or less, as-is!
Same workflows. Same projects. Same custom fields. Same complexity. Just a new URL.
The problem? When you replicate everything, you also replicate the inefficiencies, inconsistencies, and workarounds that built up over time. Worse, you miss the opportunity to take advantage of what’s actually different—and better—about Cloud.
Aaron and I have both lived through multiple Atlassian Cloud migrations. Some went smoothly. Others dragged on for months or quietly fizzled because the focus was on copying the past instead of improving it.
This article is for the administrators and decision-makers who want more than a move.
If you’re going to invest the time and energy into migration, use it as a reset.
In other words, in our experience, migration isn’t about moving systems from one platform to another. It’s about transformation.
Legacy migrations were all about parity: can we recreate our old ways of working in the new platform?
Let’s replicate all of our existing workflows
Let’s bring over all of our custom fields
How do we move every app, every project, and every permission scheme?
The result? A near 1:1 clone of the past—complete with its inefficiencies, inconsistencies, and legacy baggage.
We feel modern migrations should use a very different approach:
What do our teams actually need to do their best work?
What can we clean up, combine, or sunset?
How do we use this move to unlock new ways of working in the new platform?
It’s a shift from systems thinking to service thinking. From fidelity to fitness.
|
Old Thinking |
New Thinking |
|
Recreate what we had |
Reimagine what we need |
|
Migrate everything |
Curate what matters |
|
Preserve every detail |
Preserve what adds value |
|
Protect the status quo |
Embrace change that serves the team |
Before you move, take out the trash. Identify abandoned and/or legacy projects that are not longer relevant. Find dead, unused workflows and duplicate custom fields. Look for inactive users, duplicate groups, and mismatched permissions. Search for pages no one has viewed or edited in years.
That’s just the short list of things that are consistently ripe for streamlining. We’re just helping get started with the thought process. Make it your own.
Strive to normalize, simplify, and archive. Start fresh where it makes sense.
The move to Cloud is your chance to adopt team-managed projects (when appropriate) and streamline complex transitions and approvals. Be sure to align issue types, spaces, and automations to the way people actually work.
Don’t rebuild brittle workflows just because they’ve “always been that way.”
Some data does need to move intact. For example, regulatory or audit-trail content; active escalations and in-flight issues; critical or heavily used marketplace apps (but not the infrequently used ones or the ones rendered redundant with Atlassian Cloud capabilities).
Know what’s critical and treat it with care. Everything else? Subject to review.
When you slim down what you migrate, you speed up what you can do next: - Cloud-first features like automation, integrations, and templates - Less overhead to maintain - Easier onboarding for new users
As Aaron likes to say: "Don't look at Atlassian Cloud as just another way of hosting your Atlassian stack. Look at it as a way of accelerating work."
If transformation is the goal, the question becomes: how do you decide what stays and what goes?
Today’s migrators have a powerful new ally: AI.
Rovo can help you identify stale content in Confluence or Jira based on usage, activity, and structure. We suggest you use Rovo to:
Cluster and tag issues for bulk review or archiving
Suggest cleanups: field consolidation, duplicate permissions, unused workflows
Refactor workflows by analyzing transition logic and frequency of use
Whether you use Rovo, Atlassian built-in analytics, or third-party tools, let the your tools help you decide what’s worth saving.
What we have found: AI helps us stop guessing. It’s not just about cleanup—it’s about curation at scale.
Note: Rovo does not run natively on Atlassian Data Center. It is a cloud-native AI platform. If you want Rovo to assist, you’ll need an Atlassian Cloud instance with Rovo installed. Even a small instance will do.
Then, install and use the appropriate Rovo to Data Center connectors from Atlassian to assist with cleanup and curation.
And if you’re moving from a non-Atlassian platform, there are a large and growing number of Rovo connectors that can help you with that, too.
Chances are, your Atlassian stack reflects how your company works. So changing it represents significant organizational change. Treat it that way.
Communicate early and often
Cultivate champions inside all of your stakeholder teams
Celebrate improvements—not just successful data transfers
The lesson we've learned: even the most technically sound migrations can stumble if teams aren’t aligned on the power of Atlassian Cloud. Involve stakeholders early in requirements gathering and POC testing. Otherwise, leadership may see migration as a simple, push-button task, and users will not be sufficiently trained on the new platform.
Here’s a simple framework outlining the phases of a good migration plan, as we see it. You can customize it to fit your needs.
|
Phase |
Traditional Goal |
Transformational Goal |
|
Assessment |
What do we have? |
What’s worth keeping? What’s holding us back? |
|
Planning |
How do we move it? |
How do we redesign it for Cloud? |
|
Preparation |
Fix what breaks |
Simplify, sunset, and clarify first |
|
Testing |
Check parity |
Validate business outcomes + train champions |
|
Execution |
Cut over |
Launch with purpose + support |
|
Post-Migration |
Patch gaps |
Optimize, measure, and keep improving |
Here's what we typically tell teams when they're just getting starting with their plans for any sort of migration:
The good news?
You don’t have to bring the mess. You can bring the best. And AI can help.
Dave and Aaron are Atlassian Community Champions. Dave has experienced multiple Cloud migrations from the stakeholder/user side, while Aaron has helped guide migrations for numerous organizations. They’re colleagues at Platinum Atlassian Solution Partner, Trundl.
~~~~~~~~~~~~~~~~~~
If you’ve led a migration before, what would you do differently next time? What worked — and what didn’t?
Share your lessons in the comments so others can learn from them.
Dave Rosenlund _Trundl_
2 comments