Essay on migrating legacy web app to MVC based architecture

grahamor

Hi,

I am writing a research essay on the challenges and benefits involved in migrating a legacy web site/app to an MVC based architecture. The idea is to examine all aspects involved such as

• Why bother migrating
• Advantages/disadvantages with legacy approach
• Challenges in learning new techniques
• Server / environment modifications
• Migration timeline
• What existing components can be reused ? DB, DAL, BLL ?
• Discuss ORM and it's use in certain MVC frameworks
• Advantages/disadvantages to MVC approach
• What does the future hold, what will superseed MVC ?

This essay will not focus on a particular language/framework.

I was wondering if anyone could share any experiences they have had with migrating to an MVC architecture taking some of the above points into consideration. You can keep company/project name confidential or PM me with the details. I am asking for this because i would like to reference some real world examples in my essay.

Any info is very much appreciated.

Giblet

• Why bother migrating
  
  Usually, with regards to web frameworks, a lot of legacy stuff either hinders absolute control over each separate layer within the framework. Usually, a lot of logic is tied into the front end, or it might be difficult to get to the granularity needed, especially with frameworks that like to take control such as ASP Webforms or some php frameworks which like to render whatever the hell they feel like. So either you write a lot of custom controls or you live with it. Also, some of these older frameworks have a lot of unnecessary boilerplate. Most modern MVC frameworks have improved the separation of concerns, and incorporate modern techniques and try not to get in the way any more and allow easy extensions to each component. While this isn't always true, migration can be attractive when the legacy code is suffering from the above.
  
  
• Advantages/disadvantages with legacy approach
  
  Legacy software has all the old business rules, acquired and maintained through countless iterations, developed by people who may longer be around. There might be a lot of knowledge underpinned in the code which goes unnoticed or unknown to the person currently maintaining it. There can be the "itch" to move things on to the latest and greatest, but the danger is, that once a migration happens, there might be holes there that only become apparent much later on, when a client suddenly asks why a feature doesn't exist any more.
  
  
• Challenges in learning new techniques
  
  While a framework is supposed to do a lot of the work for you, there is a danger that old habits will creep in, presenting much of the same problems. Either the database guy isn't too good and still writes horrible queries, or the front end guy still writes business logic in controllers or the view logic.
  Any framework has a ramp-up time, and many developers might not be able to hit the ground running. A period of trial and error prototyping needs to be undertaken before a decision is made about whether or not the new framework will be a good fit.
  
  
• Server / environment modifications
  
  Servers will most likely have to be upgraded. Usually the issues that arise aren't from the new software, but the old software which relied on an older version of the currently installed libraries, which suddenly breaks and there's no-one to maintain it. Licensing also has to be looked at, say for example with the upcoming SQL Server 2012 and there per-core licensing. Migration of databases is also a key area.
  
  
• Migration timeline
  
  A lot of time needs to be put aside for research into what potential issues may arise. Introducing fail over plans, and back out plans if everything suddenly needs to be abandoned.
  
  
• What existing components can be reused ? DB, DAL, BLL ?
  
  This really all depends on how well the existing legacy code is written, and again, a lot of the legacy logic might need to be reassessed and ported over. Many of the issues might be present in these layers that the new framework was trying to solve.
  
  
• Discuss ORM and it's use in certain MVC frameworks
  
  ORMs are always a scary proposition for anyone migrating from a pure SQL / Stored Proc approach. Many will be afraid of the performance issues usually associated with ORMs (and their misuse), while others won't have the proper training to deal with them. Database schemas usually have to be reassessed to incorporate best practices when it comes to ORMs, and maintaining logic involving queries can move from a stored procedure to source code, meaning the responsibility might move from a DBA to a developer. (Think patching a stored procedure without doing a release, now think about the same thing in code). The biggest issue I've seen personally is bad joins and selects causing issues such as Select N + 1 due to the code not being correctly profiled and the queries being setup incorrectly, or no caching. This is the biggest source of all complaints about ORM performance (as well as large result sets / bulk operations, but that's using the wrong tool for the job)
  
  
• Advantages/disadvantages to MVC approach
  
  The advantages usually come from the separation of concerns as well as the fact that MVC is a good "fit" for web development and a lot has been done in this space recently, meaning that the is a good knowledge base and a lot of the latest and greatest things are being done here. The disadvantage comes from the fact that many will need to read up on new frameworks and actually think about migration plans. Also, MVC might not be the fit for what you are trying to accomplish, and might cause more problems that could have been solved easily in existing code,
  
  
• What does the future hold, what will superseed MVC ?
  
  Lighter frameworks, node.js style stuff. Don't have my crystal ball here though :S