How We Moved 300,000 Users Overnight Without Anyone Noticing

Authy announced it was shutting down. The notice was clear, the deadline was firm, and Cloudbeds had over 300,000 customers relying on it for multi-factor authentication. We had three months.

When I picked up the project, the first thing I discovered was that someone had already tried. A previous PM had worked on this and stalled. So before writing a single line of a plan, I sat down with the engineering team and read through everything that had been done so far. I wanted to understand exactly where it broke down and why.

The technical foundation was there, but it was broken too. No clear roadmap. No identified changes. No ownership. The migration had been treated as a background task rather than a product initiative, and it showed. Something this size, affecting this many users, needed a single person to own it end to end and drive it forward. That’s where I came in.

We started over.

Defining what success actually looked like

The goal sounds simple: move 300,000+ users from one authentication provider to another without breaking anything. But ‘without breaking anything’ needed a much more specific definition.

I ran a full audit of the existing work, mapped the gaps, and built a roadmap from scratch. We identified every change that needed to happen on the technical side, every risk that could surface, and every stakeholder who needed to be aligned. For the first time, the project had a clear owner, a clear plan, and a clear timeline.

We also mapped out what failure would look like. Users locked out of their accounts. A support ticket spike that overwhelmed the team. Data integrity issues discovered after the fact. Rollback scenarios that took hours. Each of these had to be addressed before we wrote a single line of migration code.

Success meant one thing: when users woke up the next morning, the only action required from them was switching the app on their phone. No login disruption. No data loss. No confusion. Everything else had to be invisible to them.

Building the plan around the user, not the infrastructure

Once the engineering team had clarity on the technical approach, I focused on what sits around the technical work. That’s where migrations like this actually succeed or fail.

I designed the user-facing communication from scratch. The messaging had to be clear, calm, and specific enough to tell users exactly what to do without creating unnecessary anxiety. Too vague and users panic. Too technical and users ignore it. We tested the copy internally, iterated, and made sure every touchpoint, email, in-app message, and help article told a consistent story.

I trained the customer support team before the migration ran. They needed to know what was happening, what edge cases might surface, and how to respond without escalating. A support team that’s surprised by a migration is a support team that creates noise. We made sure there were no surprises.

We also made a decision that might seem counterintuitive: we launched Google Social Login at the same time as the migration. The reasoning was straightforward. If users were already making a change to how they log in, giving them a better, simpler option at the same moment made sense. It turned a forced change into an upgrade.

The night it ran

We ran the migration overnight. Every phase had a clear owner, a defined checkpoint, and a rollback plan if something went wrong. The engineering team executed. As the person who had rebuilt this project from the ground up, I stayed close to every step, tracking progress, unblocking issues as they surfaced, and making sure communication went out on schedule.

By morning, it was done. 300,000+ users on Okta. Zero downtime. No data loss. Support volume stayed flat. No rollback needed.

The users who noticed were the ones who read the email we sent. Everyone else just logged in as normal, opened a different app on their phone, and got on with their day.

What this kind of project actually requires

I’ve seen migrations treated as purely engineering work, and I’ve seen what happens when they are. The technical part gets done, and then the edges fall apart. Users are confused, support is overwhelmed, and the post-migration cleanup takes longer than the migration itself.

What made this one work was having one person who owned the full picture. Not just the engineering coordination, but the roadmap, the communication, the support readiness, and the rollback planning. All of it moving together, all of it accountable to the same outcome.

The best migration is the one nobody notices. That’s what we built.