Platform
Migration.

The Mission

Fidessa is an enterprise order management system serving 600+ global financial firms and 3 million users across front office, middle office, and operations. For over a decade, it ran on a legacy Windows desktop platform built on VB6 — a technology Microsoft was deprecating.

The new web-based platform had been in development for years. With VB6 deprecation imminent, Fidessa issued a business mandate: force-migrate all users to the web platform within 9 months. My role was twofold — investigate usability concerns introduced by running both platforms simultaneously, and design an onboarding flow to prepare users for the transition.

What I found changed the shape of the project.

The Problem

Stated ask

Capture usability concerns introduced by running the legacy and new platforms side-by-side, and design solutions to address them before the February 2026 release.

Actual problem

The migration plan underestimated how disruptive the transition would be — especially for US segment users, who had been left out of the original scope entirely. Unlike European and Asian users, whose desktops would be fully native to the new platform, US segment users would work in a mixed environment: a combination of legacy and new platform tools running simultaneously, because the new platform had only ~5% feature parity with the legacy version for their regional workflows.

The original plan was to ship with 7 known concerns unresolved, then conduct usability testing post-launch to build the case for fixing them.

Why it matters: Fidessa serves 600+ global financial firms. A migration that disrupts live trading workflows is not a UX inconvenience — it is a business and revenue risk. The PM's own framing: conduct an impact assessment to avoid damaging client revenue relationships.

The Solution

Deep knowledge of how these user personas think and behave enabled me to call out the consequences of each concern before needing test data to prove them. I made the case directly, with enough specificity that the PM could act on it. Development was reprioritized. 5 of 7 critical blockers were resolved before the February 2026 launch.

My Impact

Project Impact

• Blockers resolved: 5 of 7 critical disruptions addressed before a forced migration affecting 3 million users.
• Scope correction: US segment users, originally excluded from the migration plan entirely, were incorporated as a direct result of this project.
• Launch without incident: gradual rollout completed with no notable negative feedback from clients or internal teams.

Organisational Influence

• Advocacy without test data: demonstrated that deep domain knowledge can drive development reprioritization without waiting for a usability study.
• Design as risk management: reframed UX concerns as revenue risk — the language the PM needed to act.
• Transparent communication: unresolvable concerns were documented and communicated to users proactively, rather than discovered on launch day.

Platform Comparison

The first step was understanding what users were moving from — and what they were moving to. The gap between the two platforms was wider than the project brief suggested.

For EU and APAC users, migration meant a near-complete feature transition. For US segment users, it meant working in a permanently hybrid environment — with both platforms running simultaneously and the legacy toolbar required to access tools that didn't exist in the new platform at all.

The 7 Concerns

By reviewing actual trader desktop setups across user segments and running a systematic platform comparison, I identified 7 usability concerns specific to the migration. Each was documented with context, user impact, and whether resolution required design changes or dev work.

User Context

Understanding the severity of these 7 concerns required understanding who was being migrated. Fidessa's front office traders are not typical enterprise users. They are highly habituated to their tools — desk layouts, keyboard shortcuts, and visual cues are all load-bearing parts of their workflow.

Any change — a color shift, a missing tab, a right-click menu that behaves differently — generates friction. These aren't users who adapt quickly. Their productivity depends on pattern recognition trained over years, on a platform that has been deliberately stable.

Concern Analysis

Each of the 7 concerns was analyzed against the same framework: what is the context, which users are affected, how severe is the impact, and can it be resolved by design or does it require dev work?

The US Segment Gap

The most significant discovery in the investigation phase was that US segment users had been excluded from the migration scope entirely. The original plan covered EU and APAC users, for whom the new platform had near-complete feature parity. US regional workflows had not been built out in the new platform — meaning those users faced a migration that would place them in a permanent hybrid environment with no clear path to full transition.

This was not a minor gap. US segment traders would be migrated onto a new platform while still depending on the legacy one for the majority of their daily workflows. Every one of the 7 concerns would be present simultaneously, with no relief on the horizon.

Escalating this to the PM directly resulted in US segment users being incorporated into the migration scope — not fully resolved within the timeline, but planned for and transparently communicated rather than silently excluded.

The Decision

The original plan was to ship with known concerns and address them post-launch. My collaborator and I pushed back: the concerns were more disruptive than the plan assumed, and there was no realistic dev bandwidth to fix them after launch either. The PM was presented with two options.

Making the Case

The original plan included usability testing to gather evidence. I didn't run that test — because I had enough information to make the case without it.

Making the case without data required specificity. Not "users might be confused" but "this persona relies on grouped window layouts as a workflow signal — breaking that will generate complaints from day one, before a support ticket can be raised." The distinction matters because specificity forces a decision. Vague risk assessments get deferred. Named consequences get acted on.

Each concern was framed in revenue terms: who would be affected, how many users, what they would do, and what it would cost to fix after launch versus before. That's the language the PM needed to act.

Onboarding Flow

Users opening the new platform for the first time needed to know what had changed before they encountered it. Surprises in a live trading environment erode trust immediately — and in a forced migration, the first impression is a business impression.

An onboarding announcement was the only design lever available for concerns that couldn't be fully resolved within the timeline. The goal was transparency over reassurance: tell users exactly what was different, what was being committed to, and what to do if something felt wrong.

Content covered

• The mixed tool environment — why it exists and what it means for desktop organization
• New alert functionality and where alerts now surface
• Desktop navigation changes — location of legacy toolbar in the new environment
• Notice about previously grouped or tabbed tools that may no longer be contained
• Theming acknowledged transparently — original options committed for a future release

Onboarding announcement

Alert Unification

Concerns 03 and 04 — fragmented alert delivery and configuration across two platforms — had a design solution: a single unified location for all alert management. Users would no longer need to navigate to two separate systems depending on which platform a tool belonged to.

This was proposed as part of the broader Alerts Redesign project running in parallel. The migration provided the forcing function for prioritizing cross-platform alert consolidation that was already on the roadmap — the two workstreams converged on the same architectural decision.

Alert unification proposal

Impact Documentation

Not every concern had a design solution. For the two that remained unresolvable — theming differences and layout decoupling — the work was documentation. Specific, usable documentation that gave the PM enough detail to communicate to clients and commit to future resolutions.

Layout decoupling affected less than 1% of typical desktop setups based on tool usage data — a fact that needed to be surfaced with evidence, not instinct, to avoid it being treated as a broader rollout blocker. Theming was documented as a known gap with a committed fix on the roadmap.

The output wasn't a Figma file. It was a brief specific enough that someone could act on it — including the commitment to users that original theming options would return.

What Shipped

The February 2026 launch proceeded on schedule. Rollout is gradual and tied to each client firm's update cycle — not a single cutover. The onboarding flow and unified alert configuration shipped as designed. The 2 remaining concerns were disclosed proactively and committed for future releases.