Phased WinForms Modernisation

Goal

Create a governed route from desktop to web

The goal was to use a strangler approach: introduce web capability at deliberate seams, allow modern journeys to reach established desktop screens where necessary, and retire WinForms functionality only when its replacement had been evidenced and proven.

The route needed to support users working in a customer’s Citrix or Azure Virtual Desktop estate, address the different authentication assumptions of web and Windows-hosted applications, and make each transition state understandable to engineering, product, security and operational teams.

Method

Observe, prioritise and replace one journey at a time

Application Insights telemetry and application audit trails were used to understand which areas of the desktop application were used most heavily, how users moved between capabilities and where operationally important journeys concentrated. That evidence was considered alongside business criticality, user feedback, technical coupling and delivery cost; a rarely used function could still require careful planning if its consequence or regulatory importance was high.

The resulting modernisation backlog linked each proposed uplift to its evidence, dependencies, architectural decision and intended transition state. Teams could see what remained in WinForms, what was being introduced on the web, how the two experiences would coexist and what evidence would support the next decision.

New web journeys were then introduced around selected capabilities. Where a journey still needed established desktop functionality, a registered custom protocol scheme started or activated the hosted WinForms application and carried a narrow hand-off reference. An in-application HTTP listener on the local loopback boundary supported controlled communication with the running desktop client.

The hand-off surface was deliberately constrained. Inputs required validation, sensitive tokens and business data were not placed directly in protocol URLs, and the desktop application remained responsible for authorising the requested action in its own context. This created continuity across the browser and hosted desktop without turning the desktop process into a remotely accessible general-purpose API.

Authentication was treated as an end-to-end journey. The SaaS application used modern token-based identity, while parts of each customer-hosted desktop estate still depended on Windows identity. A stable application-level identity and explicit hand-off context allowed the two environments to correlate the user without assuming that a web token could simply become a Windows credential.

The desktop and its supporting APIs were also single-tenant. Calls from the shared SaaS application passed through the governed Azure Front Door and API Management policy path, where access was validated and APIM used trusted tenant context to select the corresponding customer deployment. This kept tenant routing out of the browser while allowing the precise placement of authentication controls within the edge and API policy chain to remain an implementation concern.

Technical Challenges

Preserve one journey across two application models

Citrix and Azure Virtual Desktop each introduced session and launch behaviour that a normal browser-only journey did not have to consider. The design needed to locate or start the correct session in whichever platform the customer operated, handle an unavailable client predictably and preserve enough context for the user to continue without exposing the wider desktop application through the hand-off boundary.

Telemetry also required interpretation. A hot screen could be a strong candidate for investment or a warning that replacement would carry disproportionate risk. Audit trails showed what had happened, but product and operational knowledge remained necessary to explain why it mattered. Evidence supported accountable decisions; it did not remove judgement.

The intermediate architecture therefore had to remain current. Decision records captured why a journey stayed on the desktop or moved to the web, the evidence used, the dependencies that remained, the owner of the decision and the conditions for reconsidering it. Architecture governance became part of delivery rather than a review of a target diagram after implementation.

Outcomes

Web capability could grow around proven desktop software

Users gained modern web journeys without losing access to business-critical desktop capability. The custom protocol and loopback listener provided a bounded route into the correct customer-hosted WinForms instance, while the tenant-aware API path and telemetry created a repeatable basis for deciding what to modernise next.

The estate could evolve through visible, supportable states. Each uplift reduced the desktop surface deliberately, and the application remained operational without committing the programme to a speculative full rewrite.

Business benefits

Direct investment towards the journeys that matter

• A phased alternative to a high-risk WinForms rewrite.
• Application Insights and audit evidence used to inform sequencing.
• Business criticality and technical risk considered alongside usage volume.
• Modern web journeys able to continue into the customer’s Citrix or AVD-hosted screens.
• Trusted tenant routing from shared SaaS capability to single-tenant customer deployments.
• Explicit handling of modern web identity and established Windows identity.
• Visible transition states, owned decisions and defined reconsideration points.
• Desktop capability retired only when a replacement had been proven.

Architecture value

Architecture connected evidence, decisions and delivery

The important artefact was not only the target web architecture. It was the governed route between current and target states: usage evidence, constraints, decision ownership, coexistence boundaries and learning from each released increment. Keeping those elements connected allowed teams to change one architectural assumption at a time while continuing to explain how the live system worked.