We ship a number of windows applications. Some of the parts of each application use .NET2, some 3.5 and one application is still VB6. We have to make annual updates because the tax law changes every year (many of our users are accountants and actuaries). Refactoring code each year is a standard practice for us. When we added .NET 3.5, we were wanting WCF and Linq, and will be adding more stuff as time goes by (and we have time to learn what we want to add).
If I replace old classes with new ones, it risks functionality and need thorough testing again. If I don't, the project size is increasing.
I recommend adding unit testing to your solution. Many developers don't like to do testing, even automated testing. We have some who comment out tests that now fail due to their new code breaking some older edge case.
Three good books are:
Brownfield Application Development in .Net and
Working Effectively with Legacy Code
Growing Object-Oriented Software, Guided by Tests
If you cannot afford the versions of Visual Studio that include unit testing, then I recommend another books on using external tools for testing:
Expert .NET Delivery Using NAnt and CruiseControl.NET
While this book was written for .NET 1.1, it still has some useful information.
One practice I recommend strongly is "continuous integration." The purpose of this is for some process that runs every time code is checked in to compile and test the code. While it is fiddly and annoying to set up in the beginning, it makes things very easy and very repeatable later on. If you are keeping score, continuous integration lets you answer "yes" to questions 2 & 3 on the Joel Test.