Atlassian migration · 2024–2026
Two products, one front door
Atlassian acquired Loom in 2023. I owned the design for the work that moved 40 million Loom users onto Atlassian’s identity, billing, and admin platform — and I owned the argument that it was a product experience rather than plumbing.
One week out Enough notice to feel prepared, but not enough to build dread. The key message was what was not changing. Research showed admins’ main worry was whether their videos would survive the move.
Every day until it happened The banner was a version an admin could not miss, sitting above the product for the weeks their workspace was in line for migration.
The morning it happened A simple statement that the migration happened, what changed, and one button to acknowledge.
While looking for billing Hovering showed a preview of where you were about to land and a preview of what you could do there, rather than sending you to an unknown destination.
The upgrade decision The new AI tier was marked as recommended and sat at the end of the row. Monthly and annual prices were a toggle. A comparison table sat below the fold.
Where billing settings live now A new home rebuilt on Atlassian Commerce Platform and still understandable to someone who had only ever managed a small team Loom plan.
What happened
- Fastest
- integration in Atlassian’s history, launched 24 October 2024
- +38.7%
- over ARR forecast
- 40M
- users moved onto the new platform
“It is really difficult to overstate how complex plugging in an entirely new backend system across our most critical user journeys of sign up, provision, and billing is. Truly the most cross-functional of efforts across Loommates and Atlassian broadly.”
How it got there
The problem
Move 40 million Loom users onto Atlassian without disruption, deprecate 700,000 free roles, and remediate prices for 85% of paying customers. Every existing Loom customer would be impacted by this, and each cohort was high-stakes.
Two admin cultures
Loom admins are senior individual contributors managing small teams. Atlassian admins are IT professionals managing thousands of users in a complex admin hub. We were moving the first group into a system built for the second. Most of the design decisions on this project were guided by this fact, including the settings handoff.
There was no researcher on the migration. There was a Loom researcher running Enterprise admin work for a different team, so I went to her — research that wasn’t commissioned for you still applies to you. Then I wrote a one-pager on what a general admin study meant for migration specifically, with the source attached, which is what made it usable by anyone but me. It produced the principle the settings handoff runs on: keep the wayfinding in Loom and link out to Atlassian Admin, rather than dropping an IC admin onto a homepage built for IT professionals.
Deciding where to spend
The default position was to ship the migration quietly and cheaply, because it’s plumbing. I thought it was the product experience those users actually get, and I had to make that case without owning the roadmap or the resourcing. So I didn’t argue it as taste. With the PM and data science I mapped the business-critical flows and pulled the conversion numbers, so we were arguing about one picture instead of two adjectives.
Data Science analyzed the business-critical flows and graded them by churn risk against a benchmark of less than a 5% drop in conversion. That gave us permission to hone our focus:
- Invest in Loom-branded signup, because it sits at the top of the funnel
- Change nothing about the upgrade flows, and instead measure and learn
- Invest in admin and billing, because churn risk was concentrated
Cohorting
We kicked off with a week-long workshop at Atlassian HQ in Sydney with the User Access Admin and Commerce teams. I facilitated at the whiteboard and produced artifacts afterwards. The plan was to start with lower-risk customers to test the migration scripts, sub-cohort by churn risk determined by size of price change and free role reduction, and handle the outliers in snowflake cohorts at the end. Atlassian Commerce’s earlier platform migration had run to more than fifty sub-cohorts, which told us how granular this needed to get.
Bridging two settings systems
The gnarliest problem was structural rather than visual. Two products with completely different settings information architectures now had to behave like one. I led a group of designers to map which setting lived where, audit the redundancies, design the handoff points between them, build a repeatable pattern for bridging, and argue for the investments in them.
Sequencing the communications
Loom’s free Creator Lite role was deprecating, which meant users had to go through packaging changes as well as a new account system. I worked with product and marketing to map the full sequence: timing, channel, and content for each touchpoint. Design timelines made the sequencing legible by showing the experience as a customer would receive it rather than as a list of sends.
What it took to ship
This project required work beyond product design as it’s usually scoped:
- Influencing platform teams to adopt changes they had not planned for, including a new cancel flow and per-seat pricing
- Serving as a subject matter expert on Loom’s billing and monetization flows during the commitments process, when the Atlassian Commerce team decided which capabilities they would build for us: trial skipping, mid-cycle true-ups, and scheduled downgrades
- Building processes. There was no process for staying current on Atlassian’s admin and commerce roadmaps, so I set up 1:1s with their designers and monitored their channels to anticipate releases that affected our users.
- Coordinating eleven teams across two companies — Atlassian Admin and Commerce in Sydney and India, Data, and UXR — roughly sixteen hours of time zones on a standing basis
What I took from it
I was wrong about my own top priority
We left real things out of the initial launches, and I conceded upgrade flows, re-trialing, and per-seat pricing. Rather than fight item by item, I turned it into a bet: launch, instrument, decide at one month.
At one month the data said the upgrade flows I’d pushed hardest for barely mattered. Re-trialing, which I’d ranked lower, was the actual problem. I was wrong about my own top priority, and I only know that because I insisted on measuring.