Redesigning the migration platform from the ground up

Context

Every company's email is hosted somewhere

When companies merge or are acquired, their email platforms have to consolidate. A business on Google Workspace gets absorbed into a Microsoft environment, and every mailbox, calendar, and file has to move. IT providers manage every detail of that move for their clients. At SkyKick, the migration platform was an acquisition engine for new partners.

Google Workspace to Microsoft 365, a common email migration scenario.

Problem

A rigid flow that drove partners to support

The product ran on a backend never designed for the scale it had reached. Years of incremental fixes had left it fragmented. Support escalations ran at 15–20%, and feature velocity had slowed. The experience didn't reflect how partners actually worked. IT providers manage migrations alongside active customer relationships, but the product enforced a rigid, linear wizard. Once a migration began, many settings locked, and there was no going back.

The planner wizard and the monitor were two disconnected experiences, with no way back.

Approach

We reframed migration as orchestration

I re-examined the migration model itself. Support data and partner interviews pointed to a structural problem: the product was sequenced around the system, not the partner. I mapped the partner journey and made it visible to the team. I kept exploration loose and tested early with partners who'd grown their business with the product.

Exploring navigation models before committing to a direction; timeline view had early momentum.

Solution

One experience, with a way back

We replaced two disconnected tools with one flexible experience. Partners could watch a migration run and change it without starting over.

Faster kick-off

I cut the upfront commitment. Partners start with the essential inputs, then refine configuration as they go using discovery data from the source server.

The source server tool let partners gather configuration data before committing to setup decisions.

Migration Flights

Partners could group mailboxes into prioritized batches and stage a rollout, executives first, broader teams later. I named the feature Flights. It tested well immediately and became a marketing pillar.

In the draft state, warning patterns surface issues before a migration goes live.

Live plan reconfiguration

I made mailbox settings editable after a migration went live. The no-going-back constraint was gone, and with it the support dependency it had created.

Partners can move mailboxes between flights and apply unique configurations to each batch.

Outcomes

Less friction, more migrations

Partners finally got features they'd been asking for. For SkyKick, the redesign extended the life of its flagship product and unblocked scale with partners like GoDaddy.

“Flights, the customization, is most valuable to us. That’s going to be absolutely monumental in the control that we have on all migrations moving forward.”
— IT technician

47%

Reduction in support tickets

53%

Increase in migration projects

24%

Increase in migration seats

With more time

I’d have pushed for shared event instrumentation, Design and Product working from the same behavioral data. The flexible navigation gave partners many paths through the product, and we couldn’t see which ones they took or where they dropped off. That visibility would have been the foundation for data-driven iteration.