This is a hypothetical scenario. Let's say you've just been hired at a company with a small development team. The company uses an internal CRM/ERP type system written in .NET 2.0 to manage all of it's day to day things (let's simplify and say customer accounts and records). The app was written a couple of years ago when .NET 2.0 was just out and uses the following architectural designs:

• Webforms
• Data layer is a thin wrapper around SqlCommand that calls stored procedures
• Rudimentary DTO-style business objects that are populated via the sprocs
• A "business logic" layer that acts as a gateway between the webform and database (i.e. code behind calls that layer)

Let's say that as there are more changes and requirements added to the application, you start to feel that the old architecture is showing its age, and changes are increasingly more difficult to make. How would you go about introducing refactoring steps to A) Modernize the app (i.e. proper separation of concerns) and B) Make sure that the app can readily adapt to change in the organization?

IMO the changes would involve:

• Introduce an ORM like Linq to Sql and get rid of the sprocs for CRUD
• Assuming that you can't just throw out Webforms, introduce the M-V-P pattern to the forms
• Make sure the gateway classes conform to SRP and the other SOLID principles.
• Change the logic that is re-used to be web service methods instead of having to reuse code

What are your thoughts? Again this is a totally hypothetical scenario that many of us have faced in the past, or may end up facing.