4

We inherited a large ASP.NET website built entirely in WebForms. The website has over 200 pages, spread across 60 WebForms projects inside of the website's solution. About half of the pages are static content while the other half has a varied amount of server side complexity, mainly data capture and display. There is no use of ASP.NET web server controls as we've been phasing them out in favour of pure html. We handle SQL data via (a lot of) stored procedures on the SQL server. Our servers run Windows Server 2012 R2, IIS 7 with ASP.NET 4.5 framework.

We're researching if it's feasible to gradually convert to MVC or if a full MVC re-write is the best way to go.

To avoid becoming too broad, this question is about the general (non project-specific) procedure of converting a WebForms ecosystem into an ASP.NET-MVC ecosystem. And the specific focus is effort estimation (given the above project measurements). Own research

The reasons why we want to convert WebForms to ASP.NET-MVC are mainly:

  • routing and SEO friendly URLs,
  • better structure and separation of code,
  • the Entity Framework for central management of data,
  • scaffolding for speedy development via auto generation of code,
  • the Web API for AJAX communication and seamless update of page without refreshing, -- and to move away from the no longer supported (since .NET 5) webforms platform.

We understand that some of these concepts can be plugged into webforms but not as well integrated as in MVC. We'd like to take advantage of the flexibility that MVC offers.

So, I suppose we're going to need to do something like the following:

  • convert gradually:
    • add an MVC skeleton structure that covers a specific part (likely the site .master and respective controls (.ascx) and a single WebForms project)
    • fill in the structure with functionality, reusing relevant chunks of existing code by refactoring them as needed full rewrite:
    • create a full MVC structure, possibly creating a new project structure, re-partitioning functionality between them
    • fill it in by copy-pasting existing code or rewriting parts that are easier this way

These may be incorrect, of course; as I said, it's what we have for now. Questions:

Could you outline a high-level conversion procedure in either case?

Specifically,

  • in the gradual converting scenario, what's the most painless process?
    • To re-write and replace the site .master and dependent controls to MVC layout and views and then load the remaining yet to be converted content into the new MVC layout?
    • Or to load views into the existing master page?
    • Or can you suggest and alternative method that will minimize duplicate MVC and webforms content during the transition period?
  • in the full rewrite scenario, is it preferable to combine everything into a single MVC project, keep the existing 60 projects structure or repartition the functionality by an MVC-friendly principle? Currently the project structure matches the URL structure.

Any guidance or constructive feedback would be much appreciated.

Improve this question
5
  • Consider the cost of doing this conversion, and weigh that against the benefits. Assume the time required is triple your most pessimistic estimate. (The answer might still be in favor of a rewrite - do the math). See also Things You Should Never Do, Part I - an old article that is still true.
    – Dan Pichelman
    CommentedJun 3, 2016 at 13:17
  • I have actually already come across that article several times before : ) As developers who's sole job is to maintain this website, we worry about becoming obsolete if we don't convert to MVC at some point. It's because it's such a mammoth task that we're looking for advice on converting over a transition period. The ideal solution would be to get the current website to such a state that we could keep most of it as is while developing new features in MVC and converting one project at a time. Hence why we're looking for input from someone who hopefully has already done something similar.
    – Organic
    CommentedJun 3, 2016 at 13:29
  • I should also mention that this is the website of a large the company we work for, so cost is not as big an issue as if it were a client project. As developers we're in control of the direction of the tech of the website, unfortunately none of us would choose ASP.NET but this is what we inherited -- a massive amalgamation of spaghetti code webforms. Nevertheless it seems like a lot less effort to convert to MVC within the ASP.NET framework than to re-write everything in an alternative language, for as much as we'd like to.
    – Organic
    CommentedJun 3, 2016 at 13:37
  • 2
    What prevents you from converting one web form at a time?
    – Robert Harvey
    CommentedJun 3, 2016 at 15:22
  • @RobertHarvey The website is in constant development so converted MVC would have to co-exist with the current webforms. We're not sure how this would work with shared content such as master pages and the controls they use.
    – Organic
    CommentedJun 4, 2016 at 22:53

2 Answers 2

Reset to default
2

For a site this large, I'm going to recommend a gradual transition.

  1. Determine if you have a web site or a web application.

    Asp.Net Web applications bring a lot of their own benefits, but the most important one for you is that they have a "mixed mode" and can run both Webforms and MVC from the same application. If you have a site, you'll need to migrate to an app. It's a simple and relatively safe process. Shouldn't take more than a day or two.

  2. Identify the parts of your code that are painful to work with or change often.

    These are your first targets. You'll get the biggest bang for your buck if you tackle these first. There's no sense in "fixing" code that never changes.

  3. Invest in a refactoring tool like ReSharper.

    I seriously could not imagine undertaking such a project without a tool that helps you quickly and, more importantly, safely clean up your code.

  4. Introduce a new class library project to house your data access and common business logic.

    The project is going to be in a state of flux for some time (perhaps forever). You're going to want to centralize logic & functionality that's common to your Forms and Controllers.

    At this point, you may or may not want to introduce Entity Framework. The safest thing to do is to extract your data access into this library, introduce an interface to it and replace the ADO.Net data later with a shiny new EF one later.

  5. Have a plan.

    A project that this will quickly become a quagmire if you don't have realistic, obtainable milestones.

Lastly, consider whether you really need to move to MVC to clean this up, or if it would be sufficient to learn the Model-View-Presenter pattern and refactor your existing code into it. It's a flavor of MVC (the pattern, not the framework) that works very well with Webforms. Properly applied, it will give you many of the architectural benefits that MVC will give you.

Improve this answer
    1

    Usually, your only real option is a gradual update to new tech as you implement new stories from your backlog. That way, you continue to provide business value over time. A rewrite is a hard sell. You provide little business value during it. And then at the end the product does roughly the same thing (near-zero business value). And for a while afterward, your delivered business value is also reduced because the new code needs hardening. (Not just bugs, but also edge cases.)

    So it makes more sense to use the existing investment unless market forces prevent that (e.g. your VB 5 code won't run on Windows X). Not only the business side, but many users are resistant to replacing existing programs with brand new ones. It's simply too much change at once (unless, again, there's a compelling reason).

    If you are developing a product with a release cycle, you may have a legitimate option to rewrite. The scope of what parts you rewrite would have to fit well within the release schedule and it would have to enable some other major capability. Even this is difficult to justify without an advocate at the executive level and a market driver. (E.g. technical debt is crippling development pace, targeting .NET 5 in future products, etc).

    in the full rewrite scenario, is it preferable to combine everything into a single MVC project, keep the existing 60 projects structure or repartition the functionality by an MVC-friendly principle? Currently the project structure matches the URL structure.

    The particular platform you are using should have less organizational importance than your team and your user stories. I don't think the optimal organization can be answered without diving into those latter details. For instance, I don't really like the MVC project's default conventions for single teams. It makes more sense for multiple teams where e.g. Controllers are developed by a dev team, and Views are developed by a UX team. (More on project organization here.)

    You also have the option to deploy differently from your project structure. Just document the deployment process if it's manual. (Otherwise it will be "documented" in deployment configuration/scripts.)

    in the gradual converting scenario, what's the most painless process?

    Replacing a master page is probably too big of a first step with too much risk.

    I'd grab the low hanging fruit first -- some static pages. It will allow you to work out the kinks of deploying the new project, resolving links between the sites, and just those general new project type issues.

    I'd start looking at your upcoming user stories and identify ones where the page(s) involved could be moved over to the MVC solution easily. Not a lot of complex postback behavior to trace, for instance. Or where new functionality is needed, and you can develop a page from scratch.

    Your WebForm and MVC pages must be able to operate together, link to each other, etc. Your users may visually notice a difference in the new pages, but their ability to perform their tasks should obviously not be interrupted. Since it's (businessly-speaking) a low-value effort, any major snafu with the new effort can cause pressure from other parts of the business to cease and desist.

    In my experience, unless you make it a primary focus, your change-over may never fully finish, or it may take years. At some point you will have to specifically create migration stories, because there will be no user stories against the remaining legacy stuff. Some legacy functions just end up being too low-value or high risk to change as part of other stories.

    P.S. After you work with the MVC project for a while, you'll likely next want to convert it to HTML5/Angular and Web API. ;) I'd recommend you just skip ahead to that, but it's a pretty daunting change in skill set which your team may or may not be comfortable with before they get MVC under their belts.

    Balancing the current investment with keeping the tech relevant is a tough one. I think it's one of the reasons that "microservice" and "microapp" philosophies have become more popular as tech evolution increases in velocity. Because "micro" projects are easier to just rewrite with new tech as long as you keep the API the same. However, they have a lack of coherence that makes them difficult to manage. Having to start 5 services to repro a bug... having to add supporting functionality to 3 services and 2 apps to fulfill one end-to-end use case. Etc.

    Improve this answer

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.