The Future of Line-of-Business Applications
Expanses of Brownfield .NET Applications Ahead
While every day enchanting stories of groundbreaking and revolutionary frameworks dominate the tech headlines and clog our online feeds, substantial value persists in a forest of legacy applications constructed upon steadfast frameworks that stood the test of time. It’s line-of-business applications (LoB) that, as lame and ordinary as they may seem, take bread home and embody the cumulative wisdom and expertise garnered over years of conscientious development. A large number of these applications were built with the .NET Framework and continue running steadily on premise, both on aged desktop PCs and ultimate laptops.
The .NET Framework is now 20 years old--the same as 3 geological eras along the software scale of time. Interestingly, .NET came out at a very favorable crossroads of times. In the late 1990s, mainframe apps were old enough to justify a rewrite and the breakthrough of Internet made it appealing and plausible also to the eyes of those holding the purse’s strings. Many organizations embraced .NET and Windows Forms to keep on coding desktop applications in a modernized, client/server style. At the beginning of the millennium, in fact, Web applications were still largely perceived as freaky things to look down skeptically.
Today, it’s another business world and probably another crossroads of times. Furthermore, another breakthrough—generative artificial intelligence—looms on the horizon. It’s another time in which facing the costs of rewriting legacy applications looks overall plausible also to purse’s holders.
What is most effective way to upgrade line-of-business .NET applications?
The State of the Union
Line-of-business .NET applications are typically Web Forms and Windows Forms applications; in some cases, even former Windows Forms applications hastily (when not sloppily) converted to Windows Presentation Foundation (WPF). None of these technologies is being further developed; upgrading, therefore, means changing the technology stack.
Companies that lately embarked on such migration projects ended up with fairly convoluted architectures mainly centered on:
Mainstream frontend technologies like Angular and React to give users the thrill of a modern user experience
Some GraphQL query layer to pick up data from a variety of heterogeneous resolvers and mutators working on top of the existing—legacy—code and underlying databases
The business logic gets wrapped up in GraphQL-friendly APIs and parts of the legacy application that can’t be easily modularized survive in Docker containers and communicate in some way with the rest of the world. It works, but more often than not the final artifact is much more expensive and slower than the original.
Migrating, anyway, is a tough decision on the management side.
A big rewrite is always a fascinating option that always excite developers, but always sounds risky to management. How to blame them? Allocating substantial funds without a definite assurance of success, as competitors surge ahead, lacks any appeal. At the same time, remaining inert is equally untenable: the symptoms that brought to at least consider a rewrite won’t just naturally resolve over time.
In a nutshell, keeping LoB applications in shape over time, and in sync with the needs of the business, is an unavoidable problem. In my everyday CTO work in charge of application development, I make a point of never building applications larger than a critical size and keeping them never behind a relatively recent version of the framework of choice.
Easier said than done, though.
Now, suppose you have an old-fashioned-but-happily-working Windows Forms application—perhaps written in Visual Basic .NET. In your dream book, you may have penciled the following goals:
Nice and attractive new web user interface (Windows Forms is a desktop application)
The same proven business components for the parts of the application that need no changes
New business components to code with newer technologies
Sounds like just a wishful dream? Dream or not, it’s just what many organizations deal with.
The Canonical Approach
If you’re looking for a sort of one-size-fits-all kind of approach for migrating legacy applications, then the approach outlined above is the only plausible option, with some bitter-sweet aspects left to everybody for contingent evaluation of the impact.
Frontend heavily based on JavaScript and subsequent perennial lock-in in the framework of choice
Introduction of an additional gateway layer (and related complexity) to orchestrate communication with the legacy components
Within the gateway layer, another layer to encapsulate the legacy components and expose their core functions as API endpoints
Essentially, you end up with an architecture like below.
Refactored, the original monolithic Windows Forms application looks now much more multifaceted and complex. It is an entirely new application founded on the same beating heart, with additional features and significantly higher runtime costs (on top of the development costs paid upfront to go live).
Anything else? You bet!
First and foremost, the logic of legacy business components is unaltered. If you need to modify anything there, sadly all the architectural effort you put in won’t be of much help. Changing the legacy code remains the same problem of touching potentially fragile code: finding developers, testing for regression, compiling old technologies, deploying on physical machines.
Second, what if new functions need some transactional behavior across distinct microservices? Worse yet, what if transactions span over legacy components?
Generally speaking, distributed transactions are intricate and failure-prone operations due to the numerous components involved. Committing such transactions across different machines (when not data centers) inevitably leads to long-running processes moreover not completely reliable. So, the optimal guideline is not to resort at all to distributed transactions. With a good design and due forethought, dividing the new functions into microservices could potentially eliminate the need for inter-service transactions. Yet some more complex scenarios remain and may require maintaining consistency across new and legacy business processes. To achieve that, you can add even more complexity via 2-phase commit protocols and distributed transaction mangers or accept the system would be eventually consistent at some point in the future.
Eventual consistency, though, is the exact opposite of what users experienced before with the legacy application. In summary, the canonical approach leads to a lot of costs to rewrite and run plus a not necessarily optimal user experience made of eventual consistency and heavy client workloads.
Severing Presentation and Backend
Turning a legacy application into a microservice architecture is a high-impact rewrite approach that tends to sandbox the legacy core and integrate it with a completely new application. A legacy Windows Forms application is made of:
A user interface layer made of forms
A presentation layer made full of event handlers in code-behind classes
The two layers are tightly coupled by design and must be severed in order to migrate the application to the web. Whatever type of application rewrite you may plan, it is necessary to move code-behind classes into controllers bound to some API endpoints. In the .NET stack, the most obvious step is embedding the business code of the legacy application into ASP.NET Core controllers. Your legacy code can be recompiled for a newer .NET runtime or for a compatible .NET Standard runtime.
Once you can trigger parts of the original business logic from within a browser client, the user interface can be based on any JavaScript-intensive frontend framework but also a more traditional server-side rendering engine such ASP.NET Razor views or pages. You can even go with Blazor—version 6 or the newest version coming with .NET Core 8.
Any Windows Forms (or WPF) legacy desktop application has a user interface and a presentation layer incompatible with web technologies. It’s certainly also a matter of visual styles and component functionality but, albeit relevant, that’s not even the sorest point. For one thing, Windows and Web frontends use a different runtime host and different threading models. A Windows Forms application will likely use customizable blocking message and dialog boxes that are not natively available within any browser. More, it may be using drag-and-drop and specific graphic painting of the screen. Not to mention the programming model that is comparable to ASP.NET Web Forms but radically different in ASP.NET Core MVC.
In a nutshell, to migrate a Windows Forms application to the web you need to severe the presentation from the rest and wrap the rest in a web API layer and then completely rewrite the presentation with the web frontend technology of choice and face any possible structural rendering limitation.
Mission Is Possible with Wisej.NET
So, is migrating the frontend of a Windows Forms application to a full HTML-based web frontend a real mission-impossible task? Apparently, it is. Unless you take a look at Wisej.NET.
Wisej.NET exists since 2015 but, personally, I never heard of it till recently when porting a large Windows Forms application to the web became crucial and urgent. We looked around, examined best and worst practices, read about public case-studies and came just to the conclusions outlined so far in the article. We could have left the backend nearly intact but rewrite from scratch the presentation layer. It looked like a long-but-doable thing. We then started building a new ASP.NET Core application—our bread and butter—only to find out that linking new user interface events and existing handlers was not so direct. Many adjustments to the former code-behind handlers proved necessary and we only looked into the simplest use-cases. We were seriously concerned when we heard of Wisej.
Now, in nearly three decades of career that started with COM and Visual Basic I counted quite a few attempts of building frameworks and libraries to migrate from Visual Basic to Visual Basic .NET and from Windows to web. All the attempts I was aware of, though, went in the direction of automatically rewriting the existing code using a new programming model closer to the target platform.
In this regard, Wisej.NET is different as it just provides the “same” Windows Forms programming model over the web. It definitely replaces and rewrites the user interface but with two enormous benefits:
No need to switch the mindset of Windows Forms developers and no need to learn different best practices
No need to touch the backend, namely the code-behind classes
The slogan “From Windows Forms to Web in just a few minutes” is clearly emphatic and eye-catching. It takes minutes only for demos good for videos or conference talks. But it takes a reasonable amount of time to port large projects vital for an organization; an amount that is a fraction of the time it would take to turn the solution in an uncertain microservice architecture. And when I say “port”, I just mean releasing to production a new ASP.NET Core, Blazor-like application that is 100% equivalent to the legacy code and open to further extensions.
Last updated
