We recently came across a few potential clients with applications built around the turn of the millennium. These are business applications so presumably they have a team that is also supporting them.
We are talking Visual Basic 6 and Active Server Pages with DCOM.
Back in their day, these applications may have been well written code.
Now they want to migrate these applications to the latest .NET Framework, etc.
Back when we first moved to .NET Framework 1.1 coding best practices were quite a bit different than they are in .NET Framework 3.5 and soon, Framework 4.0.
Moving from VB and ASP to .NET put us into object oriented programming. To be honest though, it took us a few years to acquire the skills and experience to really develop good object oriented applications.
So good code today looks a lot different than good code yesterday. Things are evolving.
There are patterns like MVP and now MVC being implemented in .NET. Other technologies like AJAX, LINQ and Object Relational Mappers. WPF is supplanting WinForms, etc.
So the jump from VP6 or ASP is pretty big.
To really take advantage of the latest frameworks and best practices, they really need a team that has current "good" programming skills and experience. Maybe their in-house developers have been keeping up and maybe not.
Certainly migrating applications also involves understanding what the application does in the first place; domain knowledge. The danger is you basically end up with what you had but on newer technology. The real power is using the opportunity to make things better.
Essentially you would start from scratch but using the old system to help define user stories and tests.
However, the real take away from this discussion is…
Good code today will be tomorrow's legacy code.
So don't get too worked up about how great your code is today or striving to be perfect, for tomorrow there will be a better way of accomplishing the same things. Build good, supportable code now and focus on getting value into the customer's hands.