So, we achieved these results through . .NET to .NET Core migration The need emerged while we have been supporting a complex KnockoutJS-based web application with a server on .NET 4.5. Background The first need to migrate from .NET to .NET Core appeared while working on a KnockoutJS-based web app with a server on .NET 4.5. We had several Razor pages, JavaScript bundles in .NET Framework, and a physical copy of jQuery. We wanted to restructure many code parts in order to use the latest technologies. Thus, we decided to start with the backend towards migration. What were the core goals of .NET to .NET Core migration? First, we needed to split up the front-end and back-end logic and avoid lots of old code blocks and poor code quality. It would have helped us to accelerate the future development time and boost the page loading speed. Second, we found out that .NET Core had lots of out-of-the-box tools. This way, we saw a great benefit of migrating from .NET to .NET Core and get rid of multiple third-party libraries that would allow us to save lots of time in the future. Third, .NET vs .NET Core migration would have enabled us to use Linux thus leveraging the benefits of using Docker and Kubernetes. Fourth, we would have become able to use Visual Studio Code for development. Fifth, we intended to make our software engineers happier and motivated by using advanced and new technologies. What’s more, it’s much easier to find and recruit new developers while operating new and ‘hot’ tools. Process Now let’s take a closer look at the migration process we have undergone. Client-side To begin with, we have minimized Razor involvement and needed to build JavaScript bundles in order to somehow organize and build our client code without ASP.NET. The application still used KnockoutJS and jQuery despite the dominance of React/Angular/Vue.js. Then, we concluded to use Gulp to create JS bundles that would have greatly helped us prior to migrating our codebase to Vue and Webpack. However, bundles are still static resources which means that we couldn’t use hot reload yet, but, nevertheless, we could start taking care of server. Server-side We started our backend migration with using out-of-the-box Dependency Injection which gave us more convenience easier integration. Despite the fact that it required multiple enhancements and codebase restructure, it was also a great option to perform a code audit and add/remove/modify some functionality. During the optimization process, we moved many code parts from our filesystem and memory to the caching service (Razor/Couchbase). What’s more, we removed several blocks of code with unverified logic dedicated to threading and next made our application stateless for more greater scalability. Once done with the health-check and monitoring processes, we turned to using Azure Kubernetes Service for deployment orchestration. Roadblocks In terms of the key problems that emerged throughout the migration process, we had a single roadblock and a way-out solution. Simply put, we bumped into the lack of several important libraries supported by .NET Core and concluded to search for and utilize alternative solutions. Over time, we found out that there were no analogs to XML and decided to drop the entire XML-based functionality. So, we created a separate application for that which was a beneficial solution as we could make the required operations there avoiding runtime. This way, we reduced the server-side logic greatly and reached the last phase of making our app stateless. Takeaways We shared our brief story of migrating from .NET to .NET Core in terms of our project. Wondering what were the results of that migration? We boosted the performance of our app by 200 times compared to the old server. We drastically cut down environmental costs. In total, the migration process allowed us to save $428/mo along with the great scalability opportunities. Next, we can turn to F2 nodes on Prod and save additional $336 per month. .NET Core enabled us to perform old codebase audit and refactoring which led to better KPIs of the application. Ultimately, .NET Core helped us analyze and optimize our technical approaches multiple times. To date, we are utilizing .NET Core for all new .NET related projects in order to get all the benefits it offers. If we require some sort of a specific logic and .NET Framework is a must-have option, then we create a separate microservice for that logic only. Bottom Line We hope our case study of .NET to .NET Core migration will become helpful for you. Actually, we recommend to analyze your tech stack and always try to optimize the solution architecture by using the latest technologies which will help boost your applications’ performance. If you want to learn the case in detail, check out our case study: . .NET Core Migration Case: How We Saved $428/Mo & Boosted Performance by 200 times

2022 - HackerNoon Contributor of the Year - Funding

2022 - HackerNoon Contributor of the Year - Investing

Build custom software that rocks.

Nominated for 2022 - HackerNoon Contributor of the Year - Funding

Nominated for 2022 - HackerNoon Contributor of the Year - Investing

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

How a .NET Core Migration Saved Us $428/mo and Boosted Performance

Too Long; Didn't Read

Ascendix Tech

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How a .NET Core Migration Saved Us $428/mo and Boosted Performance

Too Long; Didn't Read

Ascendix Tech

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES