Convert WinForms to Modern Web Apps with Blazor

Blazor is a modern web framework built by Microsoft that allows developers to use C# on both client and server-sides of the application.

Blazor was released in 2018 and has been gaining popularity ever since. Microsoft is putting a lot of effort on this.
The fact that it is a technology based on Web standards makes it a safe bet for future development. Microsoft has also made the project open-source, which means that even if Microsoft decided to go in a different direction it would still be possible to have the community maintain it.

We have an Angular offering and it has advantages and disadvantages. For teams that are more used to Microsoft platforms Blazor is typically a better alternative.
We've even had customers who started developing apps in Angular or React and switched to Blazor because their developers were more productive.
The community for the JS frameworks is certainly larger, as they have been around longer, but thousands of organizations are using Blazor and it is quickly growing in popularity.

By default our solution uses Blazor server.
This has the advantage of having a quicker initial load time, and it supports scenarios where the original code wasn't built with a clear separation of concrerns.
Moving components to Blazor WebAssembly might be possible after a migration, but it is not the default approach.

WebMap for blazor has support for most of the common components and we will need to review your application to verify which elements are supported.
The migration tool is also being improved daily and new features are added all the time.

Yes, several things can make projects more complicated. Access to hardware devices, integrations with other systems and complex UI features might require additional manual changes.
Our team can help you with any of these changes, plus any additional requirements you might have

Hardware in web applications is accessed in different ways.

You can either use some IoT mechanisms that will make the hardware accessible from a web service that will in turn be accessed by the application.

Some other alternatives exist that can use a local agent or special features in specific browsers to give you access to the devices.
It all depends on the type of hardware that you're using and whether each device will have access to it or it will be a centralized device

Not by default.
The look and feel of the application will be by default very similar to the current desktop application and this is because of two factors:
- The conversion to a responsive UI is something that typically requires input from expert users.
- We try to keep it very similar to the original application so that existing users don't need to be retrained in how to use application.

Because we use standard components, once migrated the UI can be converted to a responsive UI little by little. Some clients prefer to do it focusing on some of the screens like the ones used most of the time and keeping things at configuration, windows and other things using less often the same way as they are right now.

Not by default.
The migration process maintains the existing structure of the code but moves all the components into a Blazor application. The communication between the client and the server will be done by the Blazor infrastructure using websockets using its own endpoints, which means no APIs will be created so that they are consumable by external applications.
After the conversion GAP can help you refactor the migrated code and begin extracting some APIs if some of the functionality of the application needs to be exposed externally.

Our migration tool generates a UI that closely resembles the original application by combining standard Blazor controls with custom-built Blazor elements for complex controls.
If a specific control isn't supported, our team creates a new Blazor component that mirrors the original control's behavior. Although this may take time for frequently used controls, the result is a faithful UI recreation.
For elements used infrequently, manual replacement may be more efficient than custom component development.

The application is based on a standard Blazor server architecture which means it's scalable as supported by ASP.NET.

However, there are certain limitations because the application will need to be stateful, meaning each user will have all the session data in the server at the same time.

Typically, this will mean that every user will require several hundred MB of memory to execute the application. This is probably good for a few hundred users per server.
If you want more. it's just a matter of adding additional servers and scale horizontally.

Most of our clients end up only maintaining one version of the application, the web version.
If you require clients to continue using a desktop version of the application for some reason, you might want to think about a different approach like hosting the application inside of a desktop wrapper like electron that will enable web applications to be executed as desktop apps.

Once converted, this will be a standard Blazor application, which means you can deploy it anywhere a Blazor application can be deployed.

You can use a cloud provider or choose to have your own servers if you are hosting it yourself, you can also use local servers if you want to have it accessible in an intranet only, or even in each user's computer if you need the application to be locally available for limited connectivity scenarios.

The migration process itself at least the automated part will not automatically convert the application to a multi-tenant deployment if it's not like that already.

Depending on what the current application looks like, you might want to have separate databases per client, or you might want to do some refactoring after the conversion to move all the clients to a single database. This has some security considerations, but it is a concern that's always there when switching to a single database for multiple users.

Most of our clients end up having a single deployment of the application with separate databases for their different clients. This can be configured pretty easily once the application has been converted.

Once the application is converted to Blazor, it can be modified to add any authentication or authorization mechanisms that are compatible with Blazor.

You can use your own identity providers or you can just use one of the standard ones based on Oauth that will enable new access scenarios.
In some cases, clients will want to move to a SaaS model and that means creating a completely new mechanism to create users and authorize them to use your application.
This is something that GAP can help you with.

Of course!
Our team will be thrilled to help you evolve the application from a like-for-like application that behaves just like the original desktop application and turn it into something that takes advantage of the new platform.
Whether it is taking advantage of things like AI or other existing cloud-based functionalities or just adding new features refactoring or modifying the UI and ux you name it. We have the specialist for this and we can help you get to your desired end goal.
Check out our ample services offering: https://www.growthaccelerationpartners.com/services

It might be possible to split the project in multiple phases. However, it is something that needs to be discussed and analyzed in detail to see if it makes sense.

In some cases, clients have decided to continue using a desktop version of the application and migrating certain modules that are self-contained. These modules can then be accessed from the desktop application by hosting them inside a window with a built-in browser or can be accessed independently as a standalone Web application.

This is not something that works in every case, but it is a possibility. It might also be possible to migrate some of the modules of the application and have users be redirected to these web modules while the rest of the application is still pending conversion.

We can help you plan the project so that it is optimally taken advantage of our tools and our methodology and we'll get you there in the least amount of time and with the least risk.

The conversion tool itself doesn't include generic performance enhancements. The converted application's performance will generally mirror the original desktop application's behavior.
However, migrating to a web environment may necessitate refactoring in certain scenarios. These include cases where large data loads occur in a single control or where the original application leveraged a multi-processor environment.
In a shared server environment, the performance of these specific areas may need reconsideration.
While overall performance in the migrated application will be acceptable, thorough testing and potential optimization will be crucial for areas where performance is critical or where the original application exhibited performance issues.

A major advantage of using Blazor over JavaScript frameworks is the unified development environment. Visual Studio provides a seamless experience, making the distinction between client-side and server-side code almost transparent.
While desktop developers will encounter some new elements, most aspects will be familiar. The use of C# throughout the codebase simplifies the debugging process significantly.

Licensing Model: Our tool is licensed based on the size of the application being converted. Services provided during the migration are an additional cost.

Deployment Freedom: Once converted, the application is a standard Blazor application, and any included libraries are part of your application. You can deploy it anywhere without additional fees for the converted code or our libraries.

Third-Party Libraries: You may need to verify licensing for any third-party libraries used (e.g., Kendo UI), ensuring compatibility with your deployment plans. However, this is rarely an issue, and you typically won't face runtime fees.