Cloud doesn't expose technical debt. It exposes process debt.

[#1]

One thing I've noticed across several Jira Data Center → Cloud transformations is that the biggest challenge is rarely the migration itself.

It's everything that the migration reveals.

Data Center gives teams an incredible amount of flexibility.

Need a custom workflow?
Build it.

Need a ScriptRunner listener?
Done.

Need another automation?
Easy.

Need a marketplace app to cover a specific use case?
Go ahead.

None of these decisions are inherently wrong.

In fact, many of them solved real business problems at the time.

But after years of incremental improvements, something happens...

The platform starts adapting to every exception instead of the process adapting to the business.

You end up with layers of:

• Workflows
• Scripts
• Automations
• Custom fields
• Apps
• Integrations

Each one makes perfect sense in isolation.

Together, they create complexity that's difficult to understand, maintain, and evolve.

Then comes Cloud.

And suddenly you realize the real challenge isn't:

"How do we rebuild all of this?"

It's:

"Do we still need all of this?"

That's why I believe Cloud projects shouldn't aim to replicate Data Center.

They should challenge it.

Every customization becomes an opportunity to ask:

• Does this still solve a real business problem?
• Is this process still relevant?
• Can we standardize instead of customize?
• Can we simplify instead of replicate?

For me, that's the real value of a Cloud transformation.

Not reproducing years of accumulated complexity...

But having the courage to remove it.

Because in the end, Cloud doesn't expose technical debt.

It exposes process debt.

And paying back process debt is often the hardest, and most valuable, part of the journey.

I'm curious to hear your experience.

What was the customization or process you thought was indispensable... until your Cloud migration made you question it?

[Peter Kerrigan]

Great take, and I completely agree! 

Back when I was working at a partner, the term "migration" was obviously most commonly used. Whenever I was speaking to customers, though, I preferred the term "transformation" as you have used here. 

Even if you do attempt to recreate everything in Cloud, there are inevitably going to be differences. Beyond just how a feature/function is implemented by admins; the user experience of that function is almost undoubtedly going to be different (to varying degrees).

Then comes the process debt that you talk about. The thing that none of us like to admit exists, but perhaps the most important to take action on. If you don't tackle process debt early, it will only continue to compound in Cloud.

[__ Jimi Wikman]

If organisations can handle it, then it is always better to do a greenfield transformation than go for a migration. Most organisations can't handle it, though, which is why most migrations end with a 3-5+ year cleaning/rescue plan.

Very few organisations can handle the lack of processes and governance of work. That is because they have never had to, as the teams have decided how to work for decades. It is changing now, though, which is a massive challenge for organisations and Atlassian.

[Esther Ortega]

Totally agree, and this rings very true based on what we see  in our migrations.

The distinction between technical debt and process debt is spot on. In our experience, the hardest conversations during a Data Center to Cloud migration are never about the technology — they're about the workflows nobody designed, the scripts nobody owns, the automations nobody dares to delete. Cloud stops letting you hide all of that.

What we've learned is that the migration itself is almost an excuse to have the conversations that should have happened years earlier: what still solves a real business problem, what's been kept out of inertia, and what nobody questions because it's always been there.

The framing we find useful with clients is this: a correct migration replicates the origin. An excellent migration improves on it. If after the migration users work better and IT manages better, it was excellent. If it just works, it was correct.

To answer your question: it's almost always something apparently minor — a status, a field, a transition that has been sitting in the workflow for years. Nobody designed it consciously, but when the migration comes you discover that several teams depend on it without even knowing it.