From WPF to Angular Microfrontends for a line-of-business app

In this project, we supported the transformation from WPF to Angular microfrontends for a company. The focus was on replacing a monolithic WPF application with a classic layered architecture with a modern frontend architecture, complemented by the modernisation and decoupling of the backend logic. We also took on tasks relating to security, development guidelines, and build and deployment pipelines.

Starting point

Our client was a company. The starting point was a monolithic WPF application in a 3-tier architecture that was to be transformed into an Angular microfrontend architecture. This also involved modernising and decoupling the existing backend logic and incorporating requirements for authentication, security and development processes into the implementation.

Solution

We contributed to the migration to a microfrontend architecture and delivered the transformation from both a business and technical perspective. This included modernising and decoupling the backend logic, integrating OAuth2, OIDC, MFA and asymmetric encryption, and developing development guidelines.

In addition, we defined and supported Semantic Versioning as well as build and deployment pipelines. The implementation took place from July 2023 to December 2023 in a team of 12 participants. In the project, we worked on web development and on topics relating to database development, interfaces and data migration.

Result

What was delivered was the transformation of a monolithic WPF application into an Angular microfrontend architecture. The completed project also included the modernised and decoupled backend logic, security components for authentication and encryption, as well as development guidelines, Semantic Versioning, and build and deployment pipelines.

The project ran from July 2023 to December 2023 and lasted 6 months.

Technology

• Angular for the microfrontend architecture in the frontend
• .NET with C# for backend logic
• WPF and XAML in the existing application context of the original solution
• Oracle in the database environment
• TypeScript and SCSS in the frontend
• Docker for deploying application components
• Azure DevOps for build and deployment pipelines
• OAuth2 and OIDC for authentication and identity integration
• MFA for additional security at sign-in
• PKI for asymmetric encryption

Why moving from WPF to Angular microfrontends can make sense

When modernising line-of-business applications, the question often arises of how an established desktop application can be moved to a future-proof web architecture. The step from WPF to Angular microfrontends is particularly relevant for this type of project when an application has grown over time in business terms, covers multiple areas, or is intended to be renewed step by step. Microfrontends are an architectural approach in which a large user interface is broken down into business-separated parts that can be developed independently. What matters for decision-makers is this: it is not an end in itself, but a way of clearly separating responsibilities and making changes easier to plan.

This kind of approach is especially suitable when existing functions are not meant to be replaced in one major upheaval. More typical is a controlled transition in which old and new parts coexist for a certain period. That reduces the business and organisational complexity of a complete rebuild, but it does require clear architectural decisions. These include dividing the system by business domains, shared standards for navigation and design, and rules governing which functions are implemented centrally and which decentrally.

The architectural decision is also crucial on the backend side. If frontend components are to become independent, the underlying logic usually has to be decoupled as well. Decoupling means separating functions and data access in such a way that changes in one area have less impact on others. In projects like this, the issue is therefore not just a new interface, but usually also interfaces, data flows and responsibilities at the core of the application.

Security issues need to be on the agenda early. Terms such as OAuth2 and OIDC describe established methods for sign-in and identity verification between applications and central identity systems. Multi-factor authentication adds another layer of proof to the sign-in process. Asymmetric encryption with PKI works with matching keys and is used when identities, signatures or protected communication channels need to be secured properly. The right design depends on the context of use and should be aligned from a business, technical and organisational perspective.

For companies and public sector clients, what matters is that the modernisation is not only technically possible, but also sustainable in operation, maintenance and further development. That is precisely why architecture, the security concept, standards and the delivery process are considered together in projects like these. If you are planning a similar project, you can first refine the scope with the Project Check.

How modernisations like this are typically implemented

A project to modernise an existing application usually starts not with the user interface, but with a shared understanding of goals, constraints and dependencies. In projects like these, the first step is to clarify which business areas exist, which parts are especially critical, and which technical couplings make the transformation more difficult. Only on that basis can you assess how best to break down the path from the existing application to a new architecture.

This is usually followed by an architectural and implementation view. That defines what the target architecture should look like, which frontend parts are to be separated, how they interact, and which backend functions must be available for that purpose. For decision-makers, it is important to understand that terms such as microfrontend or decoupled backend do not just describe technology. They also determine how teams work together, how changes are approved, and how responsibilities are defined.

At the same time, quality and operational requirements are made more specific. These include, among other things, sign-in, permissions, protection of sensitive data, traceability of changes, and a reliable delivery process. Build and deployment pipelines automate recurring steps from verification through to rollout. This reduces manual intervention and creates a traceable basis for releases. Semantic Versioning is a set of rules for version numbers that labels changes in a consistent way and makes coordination between the components involved easier.

In implementation, a step-by-step approach with close coordination between business stakeholders, architecture and development is usually advisable. This allows individual areas to be prepared, migrated and integrated into the overall picture without losing sight of dependencies. Especially in existing applications, it makes sense to document decisions and define standards deliberately: for code structure, UI behaviour, interfaces, error handling and security mechanisms.

Before go-live, projects like these involve not only functional tests, but also checks of integrations, permission logic and the operating model. After launch, the work typically continues with stabilisation, adjustments and gradual further development. If you want to approach a similar project in a structured way, you can first get a rough idea of the scope with the cost calculator and then discuss it in a no-obligation initial consultation.

Typical pitfalls in architecture, security and operations

When modernising established applications, the greatest risks often do not arise from individual technologies, but at the transition points: between old and new, between frontend and backend, between business logic and identity systems, and between development and operations. That is exactly why it is worth making typical pitfalls visible early on.

One common mistake is viewing the decomposition too much from a technical perspective. If an application is not divided according to business responsibilities, new dependencies quickly arise instead of clear boundaries. In microfrontend projects, it should therefore be defined early on which parts are independent, which shared components exist, and which rules apply for navigation, design and error behaviour. Without these guardrails, complexity in the new system often grows back quickly.

Another critical point is the backend. If only the user interface is modernised while business logic and data access remain tightly coupled, the new architecture will be held back. Interfaces need to be designed so that they are understandable from a business perspective, stable, and usable by multiple frontend parts. This also affects databases and integrations. If existing data structures, Oracle connections or external systems are involved, responsibilities, data ownership and migration paths should be clearly defined.

Security requires particular attention. OAuth2 and OIDC are widely used standards, but they need to be implemented appropriately in the specific application context. Multi-factor authentication raises the barrier to unauthorised access, but it also changes sign-in, support and operational processes. PKI and asymmetric encryption provide additional protection, but they require clear key management and unambiguous responsibilities. Where personal data, evidence or logging are involved, data protection officers should be consulted, and legal contacts should be involved where legal issues arise.

Operations are also often underestimated. Containerisation with Docker and automated pipelines make deployment easier, but they do not replace an operating model. In projects like these, responsibilities for monitoring, error analysis, release approvals and emergency processes must be clarified. Anyone planning a new application or application architecture should therefore think not only about development, but also plan the later hosting and operation in the Microsoft Cloud, or their own operating model, from the outset.

If you are preparing a similar project, we at ballmüller solutions will be pleased to help you structure requirements and risks at an early stage.