Redesigning the migration platform — from the ground up

Context

Every company's email is hosted somewhere

When companies merge or are acquired, those platforms often have to consolidate. A business running on Google Workspace absorbed into a Microsoft environment — 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, driving escalation

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

The legacy product: two disconnected experiences, no way back.

Approach

We reframed migration as orchestration, not a wizard

Rather than refine the existing wizard, I re-examined the migration model itself. Support data and partner interviews pointed to a structural problem: the product was built around system sequencing, not partner workflow. I mapped the partner journey and surfaced why — the product modeled a system handoff. Partners were managing a customer relationship. 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 unified experience, built around how partners actually work

The redesign replaced two disconnected tools with a single, flexible experience. Partners could now adjust, observe, and refine active migrations — without restarting.

Faster kick-off

Partners begin with just the essential inputs, gather discovery data from the source server, and refine configuration as they go — rather than completing every step before starting.

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

Migration Flights

Mailboxes could be segmented into prioritized batches, allowing staged rollouts — executives first, broader teams later. I named the feature Flights. It became intuitive in early testing and a marketing pillar.

Draft state: warning patterns surface issues before a migration goes live.

Live plan reconfiguration

Mailbox settings could be modified after a migration was active. 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 responded well — long-requested features improved the quality of their service delivery. For SkyKick, the redesign extended the life of its flagship product and primary user acquisition engine.

“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

With more time, I’d have pushed for shared event instrumentation — Design and Product working from the same behavioral data. The flexible navigation created a variety of paths through the product: what order they took, where they dropped off. Building that shared visibility earlier would have been the foundation for data-driven iteration.