Well, it certainly has been an eventful couple of weeks. Since writing the first two posts in this series, I had to take a short break for health, but now it’s time to dig back in. So, as much for me as for you, let’s reset what we’ve covered so far:
First, we cannot stay on Jira Data Center forever. That decision has effectively been made for us.
Second, there’s more than one way to migrate, and choosing a strategy that fits your organization matters far more than choosing the fastest or loudest option.
Which brings us to the next step in this series — and often the most uncomfortable one: taking an honest look at what your Jira instance is actually being used for today.
Most Jira admins believe they know their instance. And to be fair, they usually know it better than anyone else in the organization. But even the most plugged-in admin can be surprised by unknown projects, forgotten configurations, and the unintended “emergent features” that appear when real users interact with a system over time.
Because of this, there can be a meaningful difference between knowing how Jira can work and knowing how it’s actually being used at scale. That gap is where a surprising amount of migration pain originates.
So, to give ourselves the best chance for a successful migration, let’s explore how to close that gap.
The Hidden Cost of “We’ll Clean It Up Later”
Every long-running Jira instance carries baggage. How many times have you had to ask, “Who is even using this project?” How many custom fields have you tripped around that is either no longer being used, or worse yet is in use along with 3 identical fields that do the same thing? How many workflows that you can’t identify why it exists, or what makes it different from a very similar workflow, or probably most egregious, entirely inactive for no good reason?
These kind of “baggage” is cheap to tolerate. They don’t have that much impact initially, and they cost more of your time to clean up properly than it is to deal with it at some magical “other time” that never comes. That is not to lecture you – I am just as guilty of this (if not more). It’s a natural effect from the price of cleaning being far higher than the price of doing nothing. Or, that is until we start working on Jira Cloud.
Beyond the literal limits Cloud is putting onto projects, there is a real cost price to using Jira Cloud. Never manage who is on your license? You now have to pay per person. Don’t limit attachments? That now can force you onto a higher tier. Don’t keep workflows and automations under control? On the wrong tier, that can stop your automations from working.
And that is not to even consider the additional non-monetary costs that resolves from “baggage.” As I like to tell people, everything you have cleaned up now is something you don’t have to move later. Again, the edge effect per item feels small, but it adds up fast. That’s why pre-migration assessment isn’t about being tidy. It’s about being intentional.
And it’s why “we’ll clean it up later” almost never works. Once data is migrated, it becomes politically harder to remove. Teams assume that if something made it to Cloud, it must be important. You have the momentum to make changes now, but once you complete the migration, the political costs of moving became immensely larger.
Admin Intuition vs. Actual Usage
One of the most common phrases heard during migration planning is, “That project is important, we can’t touch it.”
Sometimes that’s true. Sometimes it’s just familiar.
Admins tend to remember the loud projects — the ones with lots of tickets, lots of complaints, or lots of customization. But memory is a poor proxy for usage. The projects that quietly faded away, the issue types no one questions anymore, and the fields that stopped being populated years ago rarely raise alarms.
Until they show up in Cloud.
Suddenly users are asking why there are dozens of irrelevant fields. Why certain projects appear in searches but no one seems to own them. Why workflows feel overly complicated for simple work.
None of this is malicious. It’s just the natural outcome of years of organic growth without regular pruning.
At this stage, relying solely on experience stops being enough. What you need isn’t more opinion — it’s visibility.
What “Used” Actually Means
Before going any further, it’s worth clarifying what “being used” really means in this context.
Many users – especially product managers – imagine “usage” as “has issues in it.” Just because you have a project with fifty work items that were created five years ago and not touched since may in fact count as “data”, but that does make it helpful or relevant. Likewise a custom field can exists, and even have data in it, but it may be nothing more than the Jira equivalent of “busy work.” That is to say that yes, it is data, but not work that really is helping people get things done.
When evaluating what’s worth migrating, usage questions tend to fall into a few broad categories:
So, now that we identified the problem, how do we actually identify what is actually “Used?” Lets ask a few broad questions that can help us answer this:
- Are people actively creating and updating work items recently?
- Are workflows being used regularly? Do they address common situations or only edge cases?
- Are custom fields being populated consistently?
- Are certain issue types central to work, or edge cases that stuck around?
Unfortunately, there is no real firm answer. What may count as “Recent” to one organization might be “ancient” by another organization’s pacing. Some people say any field that isn’t used in 50% of applicable work items may not be “populated consistently”, but other orgs are dealing with situations that 10% or 5% are acceptable usage of applicable work items. You might recognize that a workflow is very much an edge case, but when that situation is to prevent a problem that can have far worse effects that keeping an edge case.
That is why I am not giving hard rules for what counts as “used.” This is as much as an art as anything in Jira, and the only way to fix it is to do the hard work, ask the uncomfortable questions, and look at every object in your configuration and ask, “What is helping the users, and what is extra?”
Portfolio Insights: Replacing Assumptions with Evidence
Thankfully, Portfolio Insights becomes genuinely useful — not as a cleanup button, and not as something that tells you what to delete, but as a way to replace assumptions with evidence before you migrate. While it does not answer what counts to “Used” to you, it does make it easier to find the hard data that you can then use to start defining your own concept of “Used.”
Portfolio Insights provides a centralized view of your Atlassian footprint and includes a Cloud Readiness report that evaluates your Jira instance against migration-relevant guardrails defined by Atlassian. Instead of asking “Do we think this will migrate cleanly?”, you get concrete signals about where friction is likely to occur – based on feedback and information from Atlassian directly. For example, the Cloud Readiness report can surface things like:
- How long a migration is likely to take, based on data volume and structure
- Whether installed Marketplace apps have Cloud equivalents or compatibility concerns
- User and group considerations that may affect identity, provisioning, or permissions
- Issue, attachment, and configuration elements that exceed Cloud thresholds
- Automation rules, filters, and objects that may need rework before migration
What makes this especially valuable is that these aren’t arbitrary warnings. When something exceeds a guardrail, Portfolio Insights provides context and recommendations, often linking directly to documentation that explains why it matters and what can be done to address it.
Now to be clear – Portfolio Insights does have it’s weaknesses. Probably the most annoying is that it does it’s analysis on your entire instance. If you are taking a Phased Migration, finding actionable information on your specific situation is a challenge at best. Compounding that is when Portfolio Insights does find a configuration or issue flag, it doesn’t tell you exactly what issue or object is wrong, but instead gives you SQL statements you can then search in your database to find exact problem. That is better than nothing, but when you have everything else going on, this is one last item you need to worry about.
But, Portfolio Insights does turn vague risks into some actionable items. Instead of saying “This instance feels complicated,” you can say “Here are the areas that will materially affect migration time, reliability, or user experience.”
That shift is enormous.
What This Data Is (and Isn’t) For
So, you’ve gotten the hard data – either directly from Jira, via Portfolio Insights, from some Database Magic, or (most commonly) some sort of all three. That the hard job done, you can now just cut low usage items, and save only the most active fields, projects, or work items, right?
Unfortunately, life is rarely that easy.
It doesn’t take that much imagination to find a mission-critical process that may only happen every month, quarter, or year. A field may be lightly populated, but that is because it is only used by a small group doing compliance or reporting – information that might not apply to most work items, but a devastating if lost. A complex workflow might only be triggered in edge cases — but those edge cases might be the whole reason the business cares about Jira.
That is why before deleting something, you should be asking the following questions:
- Why is this still here?
- Who uses this today?
- What breaks if this goes away?
- What problem was this originally meant to solve?
Those conversations are far easier — and far calmer — when they’re grounded in data instead of instinct.
But also, remember before going on a massive delete-spree, backups are a relatively cheaper insurance if you delete the wrong thing…
This Is Not About Deleting Everything
From everything you’ve heard so far, I might sound like some axe-wielding barbarian, absolutely intent on removing everything possible. So before we get any further, It’s important to say this explicitly.
This step isn’t about stripping Jira down to the bone or forcing minimalism for its own sake. It’s about understanding which complexity is doing work and which complexity is just along for the ride. If something isn’t helpful, it’s causing everyone involved time, effort, and mental energy. And to be clear, that is true whether this is Jira Cloud or Jira Data Center. So while you should get rid of what doesn’t help, you should do so surgically – that is without removing anything that is serving a legit duty.
Some heavily used, deeply customized projects absolutely deserve careful migration. Some lightly used ones don’t. And some are better off being retired entirely or rebuilt fresh in Cloud. The goal isn’t fewer projects or objects. The goal is intentional complexity.
This Step Shapes Everything That Follows
Everything we have done so far – all three posts – have been just laying the foundation. And even though I presented them as separate things for the sake of teaching, I’d very much argue that Finding what you have and deciding on your Strategy should happen together – as each one can influence the other. But together, these two will move forward to impact every single decision moving forward.
Through defining what is “Used,” you can then define where the convolutions are, allowing you to decide if you can even tolerate a Phased strategy. By defining what is “Used,” you can start to figure out what Apps are optional and which ones are critical. You start defining which ones can take advantage of a Greenfield approach and get online that much faster. Basically, defining what is “Used” you start to figure out the details on how the migration exercise will proceed.
Skipping this step doesn’t save time. It prevents problems before they can be problems, and let you get an idea of what problems you can’t avoid so you can start planning the best way through. It is fun? No. Sexy? Absolutely not. Avoidable – No.
The Human Side of Cleanup
Cleanup is rarely blocked by technology problems. It’s more often than not blocked by fear.
And, that’s far. If you define from the start that you are getting rid of 30% of projects, most people won’t hear the context. They’ll see something that people created at some point in the past – and that is assumptionally for some reason good. It won’t matter to them that you have solid data and metrics saying this won’t be used, they will still see something that might be missed.
But as I said before – the fact is whether we want to or not, change is coming. Our options at this point are either move to Jira Cloud or move to something not Atlassian. This means we have the best time to write the story now. By defining this not as a cleanup, or deletion, or change, we can define it as preparation. We can let people tell we are not taking things away, we are peeling off the unhelpful extra to reveal the best parts of Jira that are actually useful for you.
That distinction matters more than most people expect.
Where We Are — and What Comes Next
So far in this series, we’ve walked through three different layers of the same reality.
First, we acknowledged the situation: Jira Data Center isn’t something we can stay on indefinitely, whether we like that fact or not.
Second, we talked about choice — that migration isn’t just a technical exercise, and that the strategy you choose matters far more than simply choosing the fastest possible path.
And now, before committing to any of those paths, we’ve grounded the conversation in awareness. Before moving anything, you need to understand what you actually have, what people are truly using, and what complexity is serving a purpose versus simply existing because time passed.
That understanding is what makes every later decision easier. Strategy stops being theoretical. App decisions stop being guesses. Cleanup stops being arbitrary. Instead of reacting to surprises during migration, you start removing them ahead of time.
Next week, we’ll move from awareness into action. We’ll take the data and signals we’ve gathered — especially from Portfolio Insights — and talk about how to interpret them in practical terms: how to decide what to migrate, what to rebuild, and what to leave behind without falling into analysis paralysis.
Because knowing what exists is helpful, but knowing what to do with that knowledge is what actually moves the migration forward.
This is Rodney, asking, “Have you updated your Jira Issues today?”
The Jira Guy 