Case study
Enterprise Migration Platform
Turning a specialist-run service into a product clients can run themselves
I led the UX and UI definition of a self-service migration tool. It replaces a process run by Asite specialists, with spreadsheets and backend logs, with a guided product where a client administrator connects their own system, reviews AI-suggested mappings and launches the migration themselves.
Strategic contribution
Defined the product model: a guided, eight-step journey that replaces a specialist-run service.
Designed reusable interaction concepts so one model works across different source and destination systems.
Decided where AI should assist (suggesting mappings) and where people must review and approve.
Role
Lead Product Designer
Team
Product · Engineering · Professional Services · QA
Stage
Discovery → Product definition → Prototype
Focus
0→1 Product · Service Design · Complex Workflows · AI
The problem
Migration was a service, not a product.
Migrating a customer onto the platform involves far more than moving files. Every step was operated by Asite specialists: setup, authentication, mapping, character rules, scheduling and validation. The tools were an Apache NiFi prototype, Excel mapping sheets and backend database logs. That created five problems:
Capacity grew with headcount, not demand. Mapping, folder creation and conversion were done by hand.
Errors were invisible. Failures were recorded in backend tables that clients couldn't see, and runs often had to be stopped and restarted.
Clients couldn't share credentials. Many were unable or unwilling to give Asite access to their third-party systems, which blocked migrations before they began.
Mapping lived in spreadsheets, with each client's own special characters and conventions.
Scale and integrity. Volumes ran from tens of thousands to 200,000+ documents, including heavy CAD and BIM files, and revision stacks, audit timestamps and CAD references had to survive the move.
The opportunity was a product that is transparent and repeatable without losing enterprise-level capability.
DISCOVERY
I triangulated three inputs from a June 2026 discovery cycle: one cross-functional scoping session, 11 stakeholder interviews (from migration team leads to a Principal Customer Success Manager) and 7 real client use cases from the UK, Middle East, USA and Europe, plus a review of the existing prototype. One constraint framed everything: Asite is always either the source or the destination of a migration.
Three personas came out of it:
Client Migration Lead: sets up and launches the migration.
Document Controller: protects metadata, statuses, revisions and naming.
Asite Migration Specialist: supports client-run migrations.
Users asked for three things: to do it themselves, easily; transparency on the process and errors; and something very simple.
Product definition
I turned a technical migration process into a product journey.
Specialists used to run six steps: setup, authentication, mapping, character rules, scheduling and validation. I redefined the experience as eight steps a client administrator runs themselves: connect, scope, map, dry run, configure, run and monitor, exceptions, report. Progress is always visible, and technical decisions are never hidden.
SCALABILITY
The product couldn't be designed around one migration path.
Because Asite is always the source or the destination, the product had to work with many different systems on the other side. I built the experience from five reusable concepts, so each new connection doesn't mean relearning the product
Source system
Where the data currently lives
Destination system
Where the data is moving
Content selection
What should be migrated
SETUP
Starting with the information needed to make the migration possible.
The first screen asks one question: where is the data moving? The client picks inbound (another system into Asite), outbound (Asite to another system) or internal (Asite to Asite), then signs in to their own system. Asite never sees or stores their credentials, which removes the biggest blocker to starting. Technical details are requested only when they become relevant, not upfront.
CORE WORKFLOW
Mapping was where technical complexity became a design problem.
Mapping turns a source system's structure into Asite's. I designed it around the questions an administrator has to answer: what was detected, how confident is the match, what still needs a decision, and what happens next. Folder mapping and attribute mapping each show source fields, Asite fields and a data preview, with a status on every row. An AI suggestion button proposes mappings, and the administrator reviews and adjusts them. Nothing is applied without approval. Missing attributes can be created without leaving the flow.
Migration needed to handle incompatibility without stopping the entire journey.
Unsupported characters and statuses are resolved earlier, through configuration, so they don't turn into failures halfway through a run. Before anything moves, the dry run previews counts, the folder tree and duplicates.
The goal wasn’t to automate every mapping. It was to reduce effort while keeping the result reviewable.
CONTROL
Not every migration should run immediately.
Scheduling is part of configuration, not an afterthought:
A migration can run once, in phases or continuously.
The dry run lets the client check the result before committing.
Active runs can be paused, resumed or stopped.
Repeated errors pause a run automatically, so a small problem doesn't become a large one.
RECOVERY
Finding an error is only useful if the user knows how to resolve it.
Previously, errors sat in backend tables that clients couldn't see. Now they appear in an exceptions list in plain language, with a way forward: retry or resolve inline, then revalidate. The path is Error, Resolve, Revalidate, Ready. A final report reconciles what was moved, and the client certifies completion, so integrity is a product feature and not a promise.
Recovery became part of the product journey, not an exception outside it.
AI OPPORTUNITY
I explored where AI could reduce configuration effort without removing user control.
I looked at two places where AI could take on repetitive setup work:
Guided setup
an assistant that helps a client through configuration.
Intelligent mapping
suggested source-to-destination mappings, each with a confidence status.
In both, AI proposes and people review. It does not run migrations on its own, and the migration stays explainable.
CLIENT EXPERIENCE
Clients needed to understand what was happening without relying on internal teams.
Five things are always visible to the client:
Configuration status
What has been completed
Validation status
What still needs attention
Migration status
Whether the migration is scheduled, running or complete
Errors
What requires action
Run history and reports
What happened in previous runs
PRODUCT PRINCIPLES
Four decisions shaped the product.
Progressive complexity
Ask for technical detail only when it becomes relevant.
Reviewable automation
AI and automation suggest; people approve.
Errors with a path forward
Every error says what happened and what to do next.
Confidence before launch
Dry run and validation show the result before anything moves.
Validation
Testing the product model before investing in the full build.
This is a 0→1 product, so I validated the product model with internal domain experts before the full build. I also defined the success measures up front. These are targets, not results, because the design is still in review:
Zero documents lost or unaccounted for, in every run
85% of exceptions resolved by the client alone
At least 85% of client admins completing the task unassisted in moderated testing, with a System Usability Scale score of 75 or more
70% of migrations run through the tool within two quarters of launch
Because this was a 0→1 product, validation focused heavily on whether the product model matched the real service, not just whether individual screens were usable.
DESIGN OUTCOME
From specialist service to structured product experience.
Guided
a client administrator runs the migration themselves, step by step.
Reviewable
AI suggestions, dry runs and reports keep people in control.
Scalable
one interaction model across different source and destination systems.
REFLECTION
The biggest challenge was deciding which complexity to remove, and which complexity users needed to see.
Migration is technical, and hiding every decision would have cost users trust. Defining what the product actually was came before refining any screen.