My team has inherited a Web Forms application that was built over the past decade or so into a monolithic code base with massive dependencies. In order to maintain this system we are going to have to spend time to break dependencies and implement proper TDD.

When I look online for guidance it seems that there are two options to move forward:

  1. Stay with Web Forms and refactor it to the MVP design pattern (thus allowing for better TDD) or

  2. Slowly migrate the application to ASP.NET MVC by rewriting it page by page using MVC (which would also allow for TDD).

Which method would be the "best practice" recommended by the .NET community today to refactor a legacy web forms code base into a maintainable application?

  • I would be averse to any approach that requires you to stay with Webforms (it's putting lipstick on a pig), but you may not have the luxury of a complete rewrite. Mar 29, 2019 at 15:39
  • What problems are you trying to solve by adding TDD to the mix? Mar 29, 2019 at 15:41
  • @RobertHarvey the code base is a master class in technical debt. massive inter dependencies within the application, not built using standard practices, dependence on out of date or obscure technologies, zero documentation. I feel that I need to be able to know if I'm breaking anything as I begin to fix bugs and add new features.
    – user321981
    Mar 29, 2019 at 15:56
  • OK, but why is TDD the cure for that? (Note that TDD and "unit testing" are not quite the same thing) Mar 29, 2019 at 19:33
  • @RobertHarvey my understanding is that the best way to deal with legacy code is testing + refactoring (citing Working Effectively with Legacy Code by Michael Feathers)
    – user321981
    Mar 29, 2019 at 21:45

4 Answers 4


There is no automated migration path from Webforms to MVC.

You will find several articles on the internet about how people have done it manually, but each involves rewriting the code, so the process that worked for them may not fit your code.

Personally I would advise either not doing it at all (Refactoring rarely pays off). Or writing a "version 2" from scratch in your desired framework. Migrating parts over to version 2 as it becomes available.

  • 1
    for the statement "Refactoring rarely pays off", is this a generally held belief in the field of software engineering, or are you saying this specifically in regards to the refactoring of this legacy web forms application? If your answer is the former ( "in general" ) how did you come to that conclusion and do you have any resources that go in depth on the topic of the failures of refactoring?
    – user321981
    Mar 26, 2019 at 21:32
  • 1
    The word "refactoring" is being misused here. Mar 29, 2019 at 15:40
  • unless your refactoring reduces the amount of electricity consumed running the application. It's always going to cost more than doing nothing. New features generate money and there are ways of adding them, even using different 'new' tech without touching the old code
    – Ewan
    Mar 29, 2019 at 15:57
  • @Ewan isn't the purpose of refactoring improvement maintainability and extensibility? When I say refactor I'm referring to improving the architecture of a system without changing its behavior for the aforementioned purposes.
    – user321981
    Mar 29, 2019 at 21:46

At the end of the day, you are doing a rewrite of your application. Whether it's little by little, or all at once, the application you end up with is completely different from what you received. There are no automated ways to make the changes you want.

Once you come to grips with that fact, you have to decide what you want to maintain in the future.

Option 1: Status Quo

  • Pro: this is the most similar to the original code, so any support you get from the previous team is useful
  • Pro: probably the least number of moving parts, and the closest to a refactoring job
  • Con: you are still dealing with web interactions you don't have direct control over (i.e. session state, when controls make calls back to the server, etc.)
  • Con: this will feel like a lot of busy work while you change how the interactions are done

Option 2: MVC

  • Pro: you can add new MVC enabled code paths alongside the legacy WebForms code in the same project. Requires some setup.
  • Pro: web interactions are more predictable, and you have more positive control
  • Con: higher risk since the end product will share almost nothing with the original project

Option 3: Something else completely

  • Pro: consistent with your team strengths or your future visions
  • Con: highest risk.

Presumably you're talking about ASP.NET Core. Because the last major release of ASP.NET MVC is over 8 years old. I hope you're not replacing a dead technology with one that is on life support.

What you need to keep in mind is that monster has a decade of decisions, behaviours and subtle side effects that could be a nightmare to replicate in a new code base. Or those behaviours may even be completely undesired so are you prepared to discuss and negotiate with the business about the new requirements? Are you prepared to be told to keep the monolith, but fix the mess in it?

Also, how much of it is covered by tests? Are you confident that when you change something, you will know very easily if you broke something or not?

If the answer is yes, then great. The code may suck, but it works, so leave it. If the answer is no, then any non-trivial change will likely bring a world of pain. I would only change the bare minimum, and if possible I would try to write some tests before I make the change - to make sure I don't break anything. In fact, writing tests first, then refactoring, is the only good way of making changes to legacy code.

Unless you're given the green light to rewrite the system, with new business requirements, with old requirements dropped or updated, then your work should be more focused and low level, and should be done on a case by case basis. But even then the result would not be significantly different to what you have now, but rather a bit cleaner and more reliable.


Have a look on Razor pages, which has a page centric architecture, similar to Webforms- https://docs.microsoft.com/en-us/aspnet/core/razor-pages/


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.