Should I Rewrite my .NET Application?

A ton of applications currently run on the .NET framework, first developed by Microsoft in 2002. But with its final major update in April 2019, only small .NET patches are planned from here on out. Microsoft has since refocused into its .NET Core framework, .NET’s cross-platform successor, released as .NET 5 in November 2020.

With .NET now old-fashioned but not entirely deprecated, devs and organizations that built on top .NET face a quandary: Do I keep my app the way it is, knowing it will become increasingly out of date? Or do I sink resources into a rewrite to leverage new and modern features?

In this article, we draw from our own customers' migration experiences as the vendor of a #1-ranked document SDK. And from these experiences, we distill and compare options to inform your decision-making on whether to rewrite your .NET application.

Here are the options we’ll look at:

As the old maxim goes, "if it ain't broke, don't fix it." The same holds for many .NET applications; If your app runs smoothly and users are satisfied, then there's almost no need to rewrite.

On the other hand, the most recent transition to Work From Home (WFH) has only put the screws to the question at hand. Many apps face increased strain on their architectures due to significant network traffic growth.

Here are some considerations to help you determine whether your migrating costs outweigh staying costs, starting with infrastructure.

.NET runs on a Windows platform, which could result in a higher application operating costs. AWS offers different pricing structures, however, which make a Windows-to-Linux comparison a bit complex. We must factor in the price of on-demand instances vs. reserved instances. For example, we can book an instance for a minimum of one year to get extra savings compared to the on-demand pricing. We'd then need to compare to the hourly rate of both reserved and on-demand according to EC2 Instances as we do here:

By the numbers, it looks like running on Linux results in 50% savings regardless if your application is deployed on an on-demand or reserved instance.

It could be that the libraries you use support .NET only and are not available for .NET 5 or .NET Core. Also, third-party providers may eventually discontinue or sunset support for .NET 4.8. It is good to get the overall list of technologies used and consider the roadmap for supporting those packages before deciding whether to switch.

From a recruitment perspective, it is harder to find .NET developers due to the ever-growing popularity of JS development frameworks. Anyone getting into development nowadays will pick the more popular framework and complete a bootcamp covering front-end and back-end development with one language. As such, this means that finding reliable .NET developers is costly.

At Apryse and our technology partner, ActivePDF, rest assured we will continue to support the .NET framework with new features planned on the horizon. In fact, we are already working on more functionality for those who want to stay with the tried and true while developing an easier upgrade path to other platforms for those who wish to switch.

If most of your development team is already familiar with the .NET stack, moving to .NET Core may prove a profitable option. In fact, Microsoft recommends any new projects should be made using .NET 5 or .NET Core. This is especially if you have cross-platform needs, use targeted microservices or Docker containers, or require high-performance and scalable systems ⁠— practically a recipe for the modern app!

.NET Core was released in 2016 as an open-source and cross-platform framework. A lot of infrastructure providers actually offer migration tools from .NET to .NET Core. One may also be able to re-use most of the existing codebase that you have written. This migration would also give developers the opportunity to refactor their code and enforce better code quality practices.

.NET Core allows you to run your applications on a Linux platform ⁠— saving you money along the way. As you probably know, the costs add up as you scale vertically or horizontally.

The current version of .NET Core is 3.1, with the end of support slated for December 3, 2022. Microsoft should provide a smooth upgrade path for anyone on .NET Core 3.1 to .NET 5 and eventually to .NET 6, according to Microsoft’s roadmap.

First announced in November 2020, .NET 5 is a Microsoft framework that merges all current frameworks (.NET Framework, Core, and Mono/Xamarin) into a single one. It enables development of applications that can be deployed on all platforms including Windows, Linux and Mac OS. If you use .NET Core 3.1 today, you should be able to seamlessly upgrade to .NET 5.

Be careful not to move too quickly on .NET 5. While it is an exciting option for a framework, keep in mind that .NET 5 hasn’t been in production for long and still needs to be proven before enterprises should make the move. .NET Core might be a solid intermediate choice, as it should make an eventual upgrade to .NET 5 or 6 seamless. At Apryse, we support both the .NET Core framework and .NET 5.0, which can save you costs by running on Linux-based machines.

Before switching to .NET Core, evaluate other options, since technology has come a long way since you originally started the application on .NET. Perhaps when the application was first built, page manipulation of a PDF seemed like a server-side-only option. Today, however, innovation in document technology has meant more and more formerly server-side-only capabilities can be safely delegated to the client.

Another interesting option is to create what is known as a serverless architecture. Serverless infrastructure hides the need for managing machines and simply lets you run code on someone else’s privately managed servers. Such “serverless” solutions are often easier to scale and are more cost-effective compared to the alternatives considered above, since you only get charged when your code runs. Additionally, due to severless support for native languages, you can often copy your previously created code to the new environment, making migration much smoother.

There are several pricing calculators available depending on the cloud storage you are considering. As a rule of thumb, however, serverless architecture provides on-demand pricing and is in most cases cheaper to run, especially if you are just starting out and growing users.

AWS Lambda natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, enabling companies to consider a broader hiring pool or leveraging existing knowledge.

With on-premise hardware, you also have to constantly update the packages and patch security vulnerabilities. Although it provides you with more flexibility, a serverless architecture pushes those concerns to the provider.

As of this writing, on AWS, there is a limit of 50 mb of deployed code, and /tmp file storage is limited to 512 mb. For example, if you are merging several PDF documents together, it might be fine for most cases.

One other limitation to consider is the time to spin up a function that has not been in use for awhile. Developers often refer to this as the “cold start” problem. However, this should not be a showstopper if the tasks are happening asynchronously and users are provided timely updates on the status of what is happening on the backend.

Serverless architecture provides a new approach to the backend. It is not overwhelming for someone to jump in, follow a guide, and copy-paste a function to run on-demand that will, in turn, scale based on demand, while someone else handles updates and security patches. These qualities make it possible to copy your function over multiple machines in various data centers, ensuring a cost-efficient and resilient backend. It's an option we and our customers appreciate as well. For example, the Apryse-powered product Xodo leverages serverless and client-side functionality for on-demand document editing needs.

Client-side frameworks have come a long way since your application was first written in .NET. As such, many functionality previously done server-side only can now be done client-side in a secure and performant way thanks, in part, to adoption of new technology, like WebAssembly. Client-side also comes with cost savings since most of the processing is outsourced to the user’s machines.

In most cases for a document management system, all you need is a client-side web application and a file storage server to start. The database also comes in handy for storing text from the documents inside of your file storage to enable search across multiple documents.

Since rendering, editing, manipulation, digital signing, redaction and other functionality can take place client-side, we no longer need to support the additional infrastructure we previously had. The user can stream the document from file storage, perform operations with a blob in browser memory, and save the updated blob back into the file storage.

Since the document is travelling less across the network, and is going directly from file storage to client, we minimize risk of attacks. You also gain better control over where the document is sent to ensure that it does not go off to any third-party servers or other jurisdictions entailing geographical compliance concerns.

The client-side approach has increased in popularity in recent years. It saves costs by pushing work to the user machines, making apps easier to maintain, and it makes hiring new developers easier. Plus, a lot of functionality once thought server-exclusive is now possible client-side, even in the user’s browser. For example, Apryse WebViewer not only offers full PDF editing capabilities in a browser, it also handles Office documents directly, without any server-side conversion. WebViewer can be integrated as a component into any web application framework, including React, Angular, Vue, and others, including Microsoft’s new framework called Blazor.

I hope that these resources help you navigate through the ever-changing landscape of application architecture. Please do not hesitate to reach out with any questions.