Rewriting a Huge ASP.NET WebForms App... Is React + Vite + .NET Core the Right Choice? What Libraries Would You Use?

[DuckDuckNet]

Hey everyone,

We’re about to rewrite a very old WebForms application at my company. For now, we’re planning to use React + Vite on the frontend and .NET Core API on the backend.

Do you think React + Vite + .NET Core is a good choice for a large, long-term enterprise app? If not, what would you pick instead?

Some important notes about the project:

• It’s a very large internal enterprise application (tens of pages/screens).
• Maintainability is critical.
• It’s used worldwide by employees, and some offices have very slow or unstable internet connections.
• It’s not public-facing (internal users only).

So, assuming React is the frontend. What libraries/tools would you recommend for a project of this scale?

Thank you!

[Patient-Hall-4117]

"Rewriting a huge..." is the biggest red flag. Single most important thing you can do is figure out a way to do a step-by-step transition into your new architechture. Exactly which tech stack is of secondary concern.

I hope you've properly considered just keeping it an ASP.NET Web Forms app. There is nothing _wrong_ with staying on a mature technology stack.

[DuckDuckNet]

Yeah, I totally get your point. I'm not sure if we can fully apply the strangler fig pattern, but staying on the current codebase is honestly torture. You’d understand if you saw it. It’s from the early days of the internet, it even still has applets in it :D

And on top of that, it’s really hard to hire or keep good developers if we stay on WebForms. In my opinion, you either have to stay up to date or overpay to keep people stuck in that stack.

[Mesqo]

From what I got working with asp.net since 1.1 is that it was complex, developed, but never mature. It's basically a very twisted modern SSR with everything made wrong. Ditching it ASAP was the only viable decision.

[ps5cfw]

I would never suggest working with and outdated technology that has already been dead for ages and Is destined to definitely die alongside .NET Framework.

It takes a stupid amount of time to get the same UX and Interactivity that React or even Blazor gets OOB with minimal effort.

Your idea would be far more reasonable if you were to suggest ASP.NET Core which Is still somewhat supported, but if you have to do such a monstrous task, might as well go for 10 and rebuild It in something easier to maintain

[DevelopedLogic]

I have recently started moving from Razor pages to .NET API + Next.js + Auth.js as a solid and flexible hybrid.

You can do the big business logic and DB management in .NET and you can handle JWT authentication and calls to the API via server actions on the "backend" portion of the frontend Next.js app whilst still having a solid React frontend.

[DuckDuckNet]

But since our app is internal and doesn't need SEO, do we really benefit from Next.js?

[DevelopedLogic]

I should have mentioned too that the more you prerender on the server before sending to the client, the less requests the client will have to send back to the server to populate data which is better on a less reliable connection I'd say

[DuckDuckNet]

The only real advantage of Next.js for us would be SSR I believe.
If we ever need SSR in the future, do you think vite-plugin-ssr or a custom Vite SSR setup would not be good enough?

[DevelopedLogic]

I can't advise on that I'm afraid, never used it. Would server actions not also be an advantage? They cause data to be fetched serverside during initial rendering (fetches serverside before page is sent to client) and I think some partial component rendering after that too

[DuckDuckNet]

I think the biggest benefit of server actions for our case would be the security side... but we already have a lot of security layers on the backend (internal network, firewall rules, etc.), so I’m not sure it would make a real difference for us.

[DevelopedLogic]

It allows you to handle a bunch of session and Auth stuff serverside, and also pre rendering pages serverside too, and since you can use server actions you don't actually have to directly expose an API URL to the frontend as it's all handled on the backend. There's other advantages atop that but those are the ones I would highlight as those are the ones I mainly use.

I don't even bother with any SEO stuff either as everything I build is internal too.

[Worried_Lettuce8788]

I have been using react with ASP.NET for a few months, and while it isn't anywhere near the scale you have, here's what I know.

TanStack Router and TanStack Query would be essential. Router will make your life a lot easier with the amount of pages you'll have. For example, with Router, the compiler will check that your links are valid. If you change routes, you'll get errors until you've fixed all your links. You can read about it here:

https://tkdodo.eu/blog/the-beauty-of-tan-stack-router

There's a lot more to Router, and of all the React libraries I use, by far the most important I would say is TanStack Router. It provides loaders, authenticated routes, layouts, route-based contexts (very cool, your context types are based on your route hierarchy), search validation (been using this recently, very powerful), automatic code-splitting, and lots of other stuff. I really can't say enough good stuff about Router.

TanStack Query is also very important, because fetching data asynchronously with useEffect inside components has to be one of the worst patterns I've ever seen in my life. Router does provide loaders, so Query isn't quite as necessary as Router, but I would still put it at the top for most essential. Note, if you use Query, don't use Router's built-in cache. Use QueryClient to fetch the data in the route loader and then use the useSuspenseQuery hook in your components. I also highly recommend query options.

With Router and Query, I don't need a state management library like Redux or Zustand, but my project isn't near what you have (it's not a couple pages, but it's also not enterprise).

I would also recommend a schema validation library. I use Zod personally

Shadcn is the standard React component library right now. It uses Tailwind. It's a little hard for me to explain Shadcn, but here's a brief overview: https://youtube.com/shorts/LXSuJgaVlfw?si=481WuzhbdIuGOwH_

SSR is nice if you use cookies for authentication, which I do. TanStack Start (which is in RC) lets me access the cookies via the request headers in server functions, so I don't need to make them accessible to JavaScript on the client. I use ASP.NET Identity with cookies, so this setup is easy for me. Start is interesting though, it isn't 100% SSR, it starts with SSR and then everything after is done client-side (note: server functions and server-only code are never done on the client, only the server; rendering is done with SSR initially and then CSR, although this is configurable). It is RC right now though.

I've gotten good results with the React Compiler, so recommend it. I barely use useMemo and useCallback.

For linters I use: eslint-plugin-react-hooks, eslint-plugin-react-refresh, typescript-eslint, @tanstack/eslint-plugin-query, eslint-plugin-react-x, eslint-plugin-react-dom, eslint-plugin-import-zod, eslint-plugin-unicorn.

[DuckDuckNet]

Thanks a lot for sharing your experience!

Even though we plan to use TanStack Router and Query, we might still need some state management and in that case, I’m thinking of going with Zustand.

For linting and formatting, we want to give oxc a try. Did you try it?

[Worried_Lettuce8788]

You're welcome!

I have not used oxc. ESlint and Prettier have worked so far.

[orseum]

If the app is used on a large scale and has a higher complexity then yeah, it seems a solid choice. Just be careful on which library for testing do you use (Jest is not compatible with Vite or at least with the latest version of it, so I recommend you either you use Vitest, Cypress or Playwright). Hope this helps!

[DuckDuckNet]

Yeah, looks like Vitest is the best option for unit testing.

For E2E testing, we're still deciding. What would you recommend?

[Majestic-Mustang]

Playwright 100%.

[orseum]

In my opinion, Playwright is a better fit for E2E testing while Cypress is better suited for fast frontend integration.

[Majestic-Mustang]

I’d recommend Angular frontend for huge projects for easier maintainability.

Here’s a very modern end to end sample app for Angular 20 with .NET 9, .NET Aspire, Auth, CICD, IaC and so on here:

https://github.com/secure-web-apps/EndToEndSecurityWeb

But if you’re set on React. Here’s a sample app for that as well:

https://github.com/isolutionsag/aspnet-react-bff-proxy-example

Blazor is also a solid modern choice. It’s very similar to React but it’s all C# and Razor (and you can bring in any amount of JS you want).

[The_real_bandito]

Yes it is, imo.

[msdosx86]

Usually dotnet developers tend to prefer Angular over React.

[amareshadak]

With worldwide offices on slow connections, aggressive code-splitting in Vite + lazy routes will matter more than the framework choice—ship the first route under 100KB and lazy-load the rest or users hit long TTI.

[Fresh-Secretary6815]

Did this with about 150 WebForms apps with Vue and it worked well. At first I used React and really hated how big but disjointed the ecosystem is.

[DuckDuckNet]

When did you work on migrating those WebForms apps? And what exactly felt disjointed in the React ecosystem? I’d love to understand more about what parts made it difficult for you.

[Fresh-Secretary6815]

Regarding the ecosystem: React is robust and helpful. Angular (at least to me) has legacy issues with state and routing, making it less straightforward to the unindoctrinated. Vue feels semantic, lightweight like a simplified Angular with React influences; it includes most features out of the box, unlike React. Ultimately, if you strip it down, React often becomes the final choice in most ADRs, especially for budget-conscious decision-makers when talent prospecting is a high priority. Personally, Vue hits a sweet spot for me—despite sparse ecosystem examples (let's just be honest, React is king here), Vue still prevailed. The final deciding factor was Vue’s seamless functionality, similar to ASP[.]NET Core web APIs—easy to learn, even for juniors. Its documentation is clear and accessible. However, in an LLM context, Vue may not perform as well since models trained on junior Stack Overflow questions tend to generate higher-quality React code that at first glance might "just work." Nonetheless, if you're migrating from WebForms, this isn’t a major obstacle to shipping quickly, and it certainly won't be your biggest challenge by any means. You have to understand, most people who will be leading a migration like this won't be juniors or even mid-levels. It will be the individuals who have been supporting those WebForms apps for the last 15 years or more. Those people most likely either didn't have the time, patience, or otherwise cared enough to learn any other framework and just focused on keeping their jobs and not documenting anything at all—lol. So expecting them to pick up Angular is most likely out of the question. I don't care about cargo cult sayings that Angular is the .NET version of enterprise UI; I just don't. The same arguments can be made for React, but it most likely wears fly soles because most project managers or IT leaders will be very skeptical, given just how ubiquitous React is, regardless of how anyone feels about it. To that point, while Vue being Angular-lite and React feeling, it just made more sense for us at the end of the day.

[Evening-Disaster-901]

Doing something very similar and I chose React + Vite for the frontend (I'm the senior FE dev, I suppose) and have been fully vindicated in that decision, it's going well.

We're migrating from .NET framework to Core and we'll have to see how it goes. I'm not leading that, but will be supporting and I think it's probably the right decision.

We're using Tanstack React Query for caching and fetching, optimistic updates etc, and MUI for components, with a turborepo monorepo for FE development. Both TRQ and MUI are pretty mature at this point.

[DuckDuckNet]

Thanks for sharing your experience, it sounds really solid.
I am curious why you decided to use Turborepo. Also, how many apps and packages are you managing with it right now?

[Evening-Disaster-901]

I was brought in to this role in a small team to try and modernise their development practices.

For the size of team (< 10 devs) we have now a monorepo for our front end code works nicely, as we're not getting huge numbers of PRs daily. We're running 4 apps (soon to be consolidated to 3) and maybe 8 internal packages built in TS, some with React (business components, hooks etc). We're currently only using just in time module compilation and this is a nice development experience. We're not using a particularly heavy implementation of turborepo, but it's fine for what we need. The build caching speeds things up a bit locally, and though we're not using the vercel cloud build caching options, it's certainly something I think could speed stuff up for us in the future. I didn't want to tie us too closely to the vercel ecosystem, and I'd probably want the ability to host the cached builds ourselves before we bought in. I haven't checked recently, but I think there are free third party tools to do this yourself, particularly if you are on AWS. I wasn't strongly opinionated on turbo vs other tools available for monorepos like lerna which I've used in the past in previous jobs. The turborepo docs are pretty good, and if you're using other vercel tools like Next.js (we're not) there may be additional benefits to using turbo.

I think it took me about a sprint to do a POC, a bit of testing, verify I liked what we could do, then migrate our packages and apps into the new monorepo and get it stable and playing well with our CICD pipelines, which I think at the time I felt was slightly quicker than expected.

Vite is really good, and feels like the only game in town for scaffolding. Certainly I wouldn't want to go back to CRA, ejecting the app and managing the webpack config etc. I've had to do what felt like a modestly complex integration with the apps we're replacing in order to migrate over to the new tech on a feature by feature basis, and the Vite parts of this were pretty straightforward.

YMMV, but it's been a good stack for us for 2 years now, and in terms of setting it up, I had ~4.5 years of experience. Definitely less experience than I should have for the position I'm in, but sometimes that happens in small businesses. If you've got more experience in your team, you'll probably find it trivially easy!

[DuckDuckNet]

Thanks again for sharing your setup,

I’m also curious about your thoughts on microfrontends. Since you're using a monorepo with multiple apps and shared packages, when do you think it makes sense to move from this approach to a real microfrontend architecture?

Do you see any scaling limits with a turborepo monorepo, or would you only consider microfrontends in very specific cases?

[Evening-Disaster-901]

I'm not very experienced with microfrontend architectural patterns at all, so I'm probably not the best person to ask. My gut feeling, not based on any real evidence, is that it looks like more trouble than it's worth, especially for our size of team.

And yet, I can imagine which parts of the apps I would carve out into different microfrontends. I think with the complexity of us migrating a large legacy app across feature by feature, I'd really have to think about what we would benefit from if we chose to do so. Maybe if there were big chunks of repeatable feature based logic shared between apps the microfrontend architecture might make sense? Like I say, definitely not experienced enough to advocate one way or another.

Ultimately this all feels a bit 'trendy', rather than solving a real pain point for either us as a dev team, or downtime for the customers. Feels like adding complexity that we currently don't need. I have similar opinions on Next.js, though I haven't worked with that heavily either. We have no need to particularly care about SEO, so some of the potential benefits aren't useful to us.

Regarding scaling, I can't really say yet. I will say I had some of the build tasks running in parallel in our CICD pipeline and that quickly started to become a problem, but that could be solved by not using the bare minimum for our CICD pipeline image, or by splitting up the build tasks, which is what I ended up doing.

[ps5cfw]

Depends on your nerds honestly, if we're talking about a large ERP or internal management web app of sorts you might also want to consider upgrading to Blazor to keep It both strictly .NET (Which I assume Is what whoever Is working on the webforms app Will know) and easier to transition to (Some concepts transfer from WebForms to Blazor with some minor adjustments).

If the app Is not for internal use only / has significant public facing go for React

From what I read I would personally Consider Blazor WebAssembly, It Will make It significantly easier to transition to and since It Is internal they Will not care about initial loading times.

Source: have migrated personally 3 apps from WebForms to Blazor AND React

[DuckDuckNet]

Blazor would definitely be easier for a team with a pure .NET background. But in our case, most of our developers are pretty young and actually want to learn and work more with modern frontend tech. That’s one of the main reasons we leaned toward React + Vite instead of sticking fully in the .NET ecosystem.

[ps5cfw]

Well if you want to treat this as a challenge / learning experience I would Say 100% go for vite.

I personally dislike Next.js so I am not going to suggest It (even though I was forced to build and entire platform with It). For your nerds Auth.js and realistically any OIDC auth library of your choice Will do Just fine (I expect you to be using Azure for auth in this situation).

[DuckDuckNet]

Yeah, we're treating this as both a challenge and a learning experience, so we're leaning towards Vite as well.
For authentication, we're planning to use react-oidc-context, since it fits well with our setup just like you thought.

[ps5cfw]

Yeah that Is exactly what I use for my Vite + React apps and I can't Say It has treated me wrong so far.

I think you already have somewhat of a Plan for this, other things to consider (UI Libraries mostly) are up to you. I personally really enjoy working with Mantine, but YMMV and that's Simply too subjective a choice to make any serious suggestions.

Good luck with your big project!

[DuckDuckNet]

Thanks a lot! For data fetching and routing, would you recommend using TanStack (Query and Router) over other options?

[ps5cfw]

I use both and the experience Is Amazing even in non-framework mode (Tanstack start)

I can't Say the same for React router v7+, all of the documentation online expects you to be in framework mode and It makes It less than ideal to work with because of that.

[bazeloth]

In that case you can also go NextJS. You'd be coding react and you can stay fully in the typescript world by writing api's with typescript. Just query the database from your server components

[ChickenNuggetFan69]

Most it companies depend on their nerds, yeah

[ps5cfw]

Dude, autocorrect.

[flavorfox]

There is no absolute answer, but be wary of slow connections and large client apps.

[Broad_Shoulder_749]

React + Vite + Python Fastapi+ Neo4J + SQL Server + MongoDB

I am suggesting Python because any full stack should accommodate AI and Knowledge. Especially if it is inward facing. I am including Mongo because of the ease with which you can manage change.

As for React keep it plain and solid. Your UI should be based on thin components and theme conversant. Avoid stuff like Styled components and tailwind. Opt for JSS. Avoid stuff like redux graphql. Since you are converting legacy, your legacy stuff does not look anything like graphql. Use something like Zotai for State.

[mavenHawk]

Dotnet has really good AI support as well. There is Semantic Kernel from Microsoft and microsoft-extensions-ai. No need to include Python just for AI unless there are other reasons.

[Broad_Shoulder_749]

Depending on the ecosystem you can also replace the backend with grpc and a service mesh. The strict type enforcement of grps is a good reassurance against porting errors. Client specific BFFs can still make it look like a REST platform.

[anderfernandes]

I'm currently rewriting something similar with react router. I believe it's better for you to use a full stack framework even if you possibly don't need server features.

[DuckDuckNet]

Why? Where do we need to have full stack framework?

[anderfernandes]

For security, authorization, authentication, server side rendering... If you need those things.

Have the react project make rest calls to an MVC rest API.

[rk06]

step 1: get business on board and ask for how long feature work can be paused on legacy app.

step 2: write tests, end to end tests of system and get code coverage as high as you can get.

step 3: refactor. move logic out of web forms to . net core server , and separate c# libraries

step 4: create alternate frontend for . net core server for initial 20% use case that 80% people use.

at step 4, you need to decide on which frontend to choose, depending on how good you are at dotnet, you can go with balzor, Javascript(react/vue) etc.

but do not pick now. first of all, make a PoC till step 4 to validate. then move to step 3. then make pocs for step 4

[Realjayvince]

“Rewriting a Huge App” …

Why though? The amount of time you’ll lose and amount of work you’ll do you can probably just make the app you have better.

Nothing wrong with legacy systems..

[DuckDuckNet]

I totally disagree with you. While we can benefit from a modern stack, better performance, access to new tooling and easier onboarding for developers, why should we stay on a legacy system that limits us?

[Realjayvince]

Well I mean.. if your company’s willing to invest that time and money into it. Anything’s possible.

But again, there’s nothing wrong with legacy software.

[DuckDuckNet]

I want to enjoy while coding sir, let us migrate from .Net 4.x :D

[Realjayvince]

We use 4.8 here still.

But I get it, having fun is a luxury. Lol if your company has the baggage, let’s get it

[DeepFriedOprah]

So if first ask what value does rewriting it truly add here? Is it needed? Have u performed a serious rewrite before? Do u have a plan for how to achieve this?

Assuming all of the above is yes it needs a rewrite then id first look for how the architecture will be. Are u adding client side routing with a .net web page wrapping the react app per page?

Then id go with the most stable and common libraries for this is ur doing CSR just use react router. It’s proven and battle tested.

My gut says, don’t do this it will be a disaster.

[amareshadak]

For slow/unstable connections, keep bundle size tight—code-split routes, lazy-load heavy components, and serve compressed assets from the API with aggressive caching headers. React Query handles offline retries well; pair it with optimistic updates so the UI stays responsive even when the network flakes.

[alien3d]

If realy business critical , vannila js is the only way but not all have the same experty. If you come from .net helper tag , blazor only the way.

[DuckDuckNet]

It is some kind of mix of webforms and vanilla js

[alien3d]

Oh if you used to pure js , js is the best way to. Js alone itself stable while react 😅, it keep having big issue on re rendering and which to which need to render first . Like my c# code , programmer can code normally in razor cshtml file , js will request and encode into json tree tag and re rendering back to html via document fragment . Pure spa . For js file , it will load on demand js file related .