Lift and Shift Is Not “Lift the Mess” in Your Jira Data Center to Cloud Migration
Atlassian’s guidance and give Jira Data Center customers a clear message: Cloud is the future, and for most instances under 10,000 users, the recommended path is a lift and shift migration. Larger instances are encouraged to work with Atlassian or a cloud-specialized partner to explore phased or more complex approaches. MAGIC 5 framework
On paper, the migration sounds straightforward. Move Jira in one controlled downtime window, do some prep, test a few times, and you are done. Victory is at hand.
In practice, there is a quiet but important gap here: cleanup is described in a single bullet point inside a list of lift and shift activities, and its importance is greatly understated.
When i hear “lift and shift”, I think “move everything as it is”, and I think most teams think the same. That is not actually what Atlassian is recommending , and it is definitely not what you want to do with a Jira or Confluence instance that has been running for years.
What Fast Shift Says, and What People Hear
In the Fast Shift guidance, lift and shift is defined as a migration that happens in a single downtime window, after careful planning and data preparation. Atlassian explicitly calls out:
- reviewing and cleaning up your data
- choosing what apps, projects, and spaces to migrate
- pre-migrating users and attachments
- running test migrations and UAT
So cleanup is there, but it sits alongside several other tasks, making it easy to mentally downplay. The headline that tends to stick is “single downtime window” and “migrate your instance.”
From there, it is a short step to the default mental model:
“We will move everything now and tidy it up later in Cloud.”
That assumption is convenient, understandable, and wrong. For long-lived Jira and Confluence instances, cleanup is not a nice to have. It is often the difference between migrating a platform and migrating a problem.
Long-Lived Jira Instances Carry Quiet Debt
Even in organizations that prioritize governance, Jira accumulates silent debt over time. Ownership changes, teams shift, and retention policies evolve, yet the configuration continues to grow. Cleaning the instance, though important, often falls behind other tasks.
On the Jira side, that often means you are carrying:
- archived or legacy projects that are rarely accessed or outside your data retention period
- large volumes of old attachments that are backed up elsewhere but still contribute to your instance size
- filters and dashboards with no subscribers, or owned by people who left years ago
- inactive workflows, unused screens and schemes, and issue types that no current project uses
- disabled or abandoned automations that no one quite dares to delete
Confluence tells a similar story in a different shape. Dormant team spaces, personal spaces for departed users, outdated page trees that nobody wants to take responsibility for, content that is effectively abandoned but still shows up in search
If you lift and shift all of this as is, Cloud will faithfully reproduce every piece of sprawl and indecision. It will come along for the ride, take up space in Cloud, and continue piling up over time.
Why Cleanup Deserves Its Own Workstream
There are three reasons cleanup should be treated as deliverable in your migration, not a background activity:
First, size and safety. Trimming old projects, attachments, spaces, and content reduces the amount of data you are trying to move in a single window. Smaller payloads mean shorter downtimes and fewer nasty surprises when you hit the “go” button.
Second, risk and compliance. Old data is not just clutter. It can be out of alignment with current retention policies, privacy expectations, or regulatory requirements. A migration is an ideal moment to reconcile what you store with what you actually need to keep.
Third, future agility. Every unused workflow, field, scheme, and space makes the system a little harder to understand, support, and evolve. Arriving in Cloud with a leaner model is one of the best gifts you can give your future self and whoever inherits the admin role after you.
Even if Atlassian or a cloud-specialized Solution Partner is involved, cleanup is still primarily admin work. Partners can bring patterns, tooling, and best practices, but they do not know your instance, your politics, or your governance history the way administrators do. Administrators usually know which projects are sensitive, which “temporary” workflows became permanent, and where instance current guardrails have failed. External experts can help design better structures in Cloud, but once the migration is over it will be governance that keeps the new instance healthy. That is exactly why cleanup is such a good fit for the in-house admin team: it is not just deletion, it is reconnecting configuration to reality and making it last after the consultants have gone home.
That is why treating cleanup as a small preparatory step understates its importance. For many organizations, it is a project within the project.
“Ideal End State” Should Include Governance, Not Just Design
Fast Shift talks about developing your ideal end state in Cloud. That is exactly the right idea, but it is easy to interpret it narrowly as “design some better workflows.”
A more useful interpretation is this:
If your current instance needs a lot of cleanup, your governance is part of the problem, not just your configuration.
The migration is a chance to ask bigger questions. For example:
- Do you really need that many global issue types and custom fields, or did they grow organically?
- When should new schemes and workflows be created, and who approves them?
- How do you want to manage Marketplace apps, and who owns each one?
- What is the minimum set of patterns you want every team to use, unless there is a very good reason not to?
In other words, do not only redesign the end state. Redesign the rules and habits that govern how it will evolve. If you copy your old governance model into Cloud unchanged, it will eventually produce the same kind of sprawl.
Treat the Migration as a Transformation
So what does this mean if Atlassian is saying “lift and shift” and you just want to get off Data Center in time?
It does not mean you need a multi-year transformation programme before you can move. It does mean that:
- cleanup deserves its own plan, owner, and timebox
- design of the Cloud end state should explicitly include governance decisions
- “we will fix that later” should be the exception, not the rule
There will always be some compromises. You cannot clean and redesign everything before you move, and that is fine. The key is to be intentional about what you bring with you and what you leave behind.
A good migration gets you to Cloud with minimal disruption. A great migration uses the same effort to reduce debt, tighten governance, and give your teams a platform that feels simpler and more coherent than the one they are leaving.
Fast Shift and Magic 5 are useful guides to the mechanics of getting there. The piece that deserves more emphasis, in my view, is this: lift and shift is should not be interpreted as lift the mess.
Thinking about a Jira or Confluence migration and not sure where to start with cleanup? Say hi in the comments and tell me what your biggest headache is.
Was this helpful?
Thanks!
Artem Taranenko
2 comments