Overcoming the Business Hurdles of Adopting .NET (Continued)

To manage this development effectively, partition your projects into legacy and .NET pieces that can be developed in isolation. Use component-based development to define common interfaces that the teams agree on. Then develop the components using .NET if it makes sense, or continue using VB6, ATL, or MFC if you're maintaining a large legacy code base that you can't afford to port to .NET.

Timing is Everything
After you've factored costs, training, and project management into your .NET migration plan, you obviously have to time your .NET adoption right. If your team of developers is halfway done with a set of ATL components, you wouldn't direct them to now develop those components in .NET just because it's released. However, this might make sense if those components are the first set of components of a larger system development planned as part of a completely .NET system.

As mentioned earlier, wholesale adoption of .NET for new projects from their inception is the cleanest way to go. If your project has a significant amount of work complete, or you're maintaining and enhancing a large fielded system, it's much tougher to decide when to bring .NET into the mix. If the product only has a few years of life left, don't bother. The costs in complexity, training, and performance penalties for interoperability will probably outweigh the benefits of small amounts of .NET code. But if the project has an expected lifetime that exceeds a few years, then it might be feasible to try to migrate the entire system to .NET over time. Do this by progressively introducing new modules as .NET components or applications, and porting the code or logic from existing modules to .NET if they need significant rework or modification because of other development changes.

The stability of your personnel might also factor into your migration timeline. If your staff is about to undergo significant growth or change, nail down your .NET migration strategy first—before making the staff changes. The type of personnel and the desired skills mix could vary significantly if you choose to use legacy technologies or .NET technologies. For example, legacy Web apps need skilled scripting programmers, while .NET Web apps need skilled OO programmers with Web development experience. If you have legacy C++ apps, you wouldn't want to hire a pure VB programmer to maintain your code. However, for .NET development, VB programmers can work side by side with C++ and C# developers, because they're all using the same model and libraries in the .NET Framework. It then just becomes a difference in syntax instead of a completely different programming model, as it is now.

Migrating to .NET is a significant undertaking, with potentially expensive implications in the near term. But many industry analysts and developers who've been studying .NET come to the same conclusion: the longer-term benefits of productivity, capability, and maintenance savings are likely to prove worth the investment.

About the Author
Brian Noyes is the software engineering manager for Digital Access Corporation. He is an MCSD with over 10 years of software and systems engineering experience. He is a technical editor and frequent contributor to Visual Studio Magazine and .NET Magazine. E-mail him at bnoyes@domeworks.com.