Atlassian Migrations — Nobody's Paid to Make It Smaller (Including Me)
Mihai Perdum
Author
7 min readJuly 6, 2026
Nobody on your migration is paid to make it smaller.
Not your migration partner. Not your app vendors. Not the admin who could tell you, off the top of their head, exactly which half of it should never move.
Not even me.
And I make more when it stays big. So read the rest of this knowing exactly who's telling you.
In my first post on migrations I argued that waiting for perfection is the most expensive mistake an organization can make. In the ones since, I've written about the app problem nobody warns you about and the three pre-migration fires that quietly torch budgets. This one is about money. Specifically, whose.
Because there is one piece of advice that shows up in every migration blog, every kickoff deck, every vendor webinar and every LinkedIn post from every consultant, me included. Clean up before you migrate. Archive the dead projects. Delete the ghost users. Retire the custom fields nobody's touched since 2017.
It is the single most-repeated sentence in the entire Atlassian migration world.
It is also the advice almost nobody takes.
And when advice fails that universally — when thousands of smart, well-funded, genuinely competent teams all nod along in the kickoff and then all do the exact opposite — the problem is not the people. The problem is the advice, and everything sitting quietly behind it.
The advice everyone gives and no one takes
Migrating to Cloud, forever. The last one percent is where projects go to die.
You didn't clean up because you're undisciplined. Your data's a mess. You ran out of runway. You know how it is.
No. I've watched disciplined teams, with clean intentions and real budgets and a project manager who colour-codes their Gantt chart, migrate a decade of accumulated sludge straight across the wire without deleting a single thing. Discipline was never the missing ingredient. And it certainly wasn't time — eighteen months is a preposterous amount of time in which to delete a custom field. If time were the constraint, the field would be gone.
Something else is holding the delete key down. Something nobody says out loud because saying it out loud is awkward for everyone in the room, including the person you hired to be honest with you.
The cleanup has no owner
The reason your instance arrives on Cloud exactly as bloated as it left Data Center is that the cleanup has no owner, and the migration doesn't give it one. It just drags the vacuum into the light and points at it under a deadline.
Think about who is actually in the room when the migration starts, and think about what each of them wants — not the noble version they'd say in the retro, the real version their compensation quietly rewards.
Every one of them, structurally, wins when more moves and loses when you stop to shrink it.
Follow the money
Your migration partner is scoped and billed to move what is there. Their statement of work is written against the instance as it exists — the project count, the workflow count, the data volume, the app list. If you spend six weeks deleting half of it before they start, you've just deleted half of their contract. Nobody writes a proposal that says "we'll help you need less of us." The honest ones will absolutely advise you to trim. But advice is free, and the invoice is written against the thing that didn't get trimmed.
The Marketplace apps are priced by user tier. Every dormant account you drag across pushes you toward the next band — and a vendor has precisely zero commercial reason to help you find the four hundred accounts you're about to start paying for. Their best-case outcome is that you migrate everyone and audit nobody.
The admin — the one person who genuinely knows what should die — carries all of the risk and none of the reward. Delete the wrong group and break a permission scheme feeding the CFO's dashboard, and it's their name on the incident. Delete the right two hundred things and save the company real money every month, and nothing happens. No thank-you, no bonus, no line in the review. When the downside is a career event and the upside is silence, the rational move is to touch nothing and let it all migrate. So it all migrates.
And then there's me.
Including me
I am a migration consultant. I am paid to move your instance to Cloud. My effort, my timeline, and a good chunk of my invoice scale with how much there is to move and how hard it is to move it.
If I talk you into deleting forty percent of your estate before we start, I have just made my own engagement smaller, shorter and cheaper. Every incentive I have points the same direction as everyone else's at that table. Move more. Move it faster. Sort it out on the other side.
I'm telling you this because it's the one thing that makes the rest of this trustworthy. I'm not standing outside the machine describing it. I'm a moving part. The advice to clean up is correct and it is given, sincerely, by the exact people — me included — who make more when you ignore it. Nobody's twirling a moustache. It's just four sets of incentives quietly pointing one way, and a piece of advice pointing the other, losing every single time.
Nobody in the room is paid to make it smaller.
What lift-and-shift actually costs you
Here is why it matters, and why "we'll clean up on the other side" is the sentence I've watched cost companies the most.
Data Center was priced per tier. Once you were inside a user band, another few hundred dormant accounts cost you nothing. Bloat was free. It sat there for years precisely because it was free to let it sit.
Cloud is priced per active user, per month. The moment you lift-and-shift, every one of those still-active dormant accounts — the departed contractors, the duplicate profiles, the service account somebody made in 2018 for an integration that no longer exists — stops being free clutter and becomes a recurring line on a monthly bill. You are now paying rent, forever, on a workforce that left. And because nobody ever gets around to deactivating them, nobody ever feels the moment it became expensive. It just is.
Then it compounds. During the overlap window you're often running a Data Center licence and a Cloud licence for the same third-party apps at the same time, and the vendors who don't offer free dual-licensing bill you twice for the whole overlap — right when the migration itself is already stretching the budget. And the tier traps are brutal: a compliance requirement that technically applies to a handful of users can force your entire seat count onto the most expensive plan, because everyone on a product sits on the same tier. I've watched a six-person requirement re-price a whole company.
None of this shows up in the migration proposal. All of it shows up on the invoice, every month, after everyone's gone home and called the project a success.
Migrating 100% isn't the goal — it's the failure
Full fidelity is how you avoid deciding what mattered.
The stakeholder who insists on full fidelity — every project, every workflow, every field, every script, migrated exactly — is usually the one who'll carry the blame for whatever doesn't come across. Asking for full fidelity feels like rigour. It's usually fear — the fear of being the person who decided wrong.
And the migration is the one moment in a decade when you actually have the leverage to make those calls. Everything is already being touched, moved, re-examined, budgeted for. The org's attention is on the system for once. That is the cheapest that deletion will ever be. Six months after go-live, when the attention has moved on, nobody is ever going back to clean Cloud — it's just the new place the sludge lives, except now you're renting it.
Sixty percent migrated decisively beats a hundred percent that never ships. I've never once regretted what I convinced a client to leave behind. I've repeatedly watched the chase for the last slice eat quarters.
The one question nobody asks at kickoff
At the start of your migration, look around the room and ask the one question the whole structure is arranged to avoid: who here is actually rewarded for making this smaller?
If the honest answer is nobody — and it usually is — then the cleanup was never the problem. The incentives are. And no amount of good intentions fixes an incentive problem. You have to change the incentive.
Scope your partner on reduction, not just execution — write the target into the statement of work and pay against it. Name a single person with the standing and the air cover to say "this dies," and protect them when they use it. Put the number of accounts and projects and fields you're retiring on the same dashboard as the migration progress bar, so shrinking is a win somebody gets credit for instead of a risk somebody quietly absorbs.
That's the job I've decided to make LeanZero — the person you can pay to make it smaller, whose whole incentive is the reduction and the audit that proves it, precisely because everyone else's points the other way. I'd rather be honest about why that role exists than pretend the rest of the table is neutral.
The clock you can't argue with
And you don't have the luxury of putting this off, because the ground under Data Center is on a fixed timer, and it's earlier than most people think.
"We have until 2029" is the dangerous lie. There are two earlier doors.
Everyone anchors on 2029. But there are three doors, not one.
After 30 March 2026, no new customer can buy Data Center at all. After 30 March 2028, even existing customers can't buy expansions — no new seats, no new Marketplace apps. So if your headcount grows in 2028, you can't licence the extra people on the platform you're still on. You're forced to move mid-flight, on the platform's schedule, not yours.
And on 28 March 2029, the subscription doesn't just lose support. It expires, and the instance goes read-only. Your Jira and Confluence keep running, but nobody creates or edits an issue or a page ever again. A decade of your company's work, frozen into a museum exhibit you can walk through but never touch.
Enterprise migrations run eighteen to twenty-four months. Subtract that from 2028 and the honest start line is not "sometime before 2029." It's now. And every Data Center customer on earth is funnelled into the same narrow window, competing for the same finite pool of people who actually know how to do this.
So, the question
There's a second migration behind this one — the platform you're racing to isn't quite the finish line either — but that's the next post.
For now, one question. On your migration, the one you're planning or the one you're already halfway through: who in that room is actually paid to make it smaller?
If you can't name them, you already know how big it's going to arrive.
Bitbucket App Passwords: What Actually Breaks, and Why Your Fix Didn't Work (2026)
App passwords are removed on 28 July 2026, and in the final week they were already dark 20 hours out of every 24. Here is the failure signature, the three different usernames nobody can keep straight, why swapping in a token often changes nothing, and the reason almost no team can tell you who is still affected.
