Introduction
In the past, Visual Basic (VB) upgrades were fairly painless and inexpensive because Microsoft made new versions of VB backward compatible, but things are different this time. An upgrade to .NET brings with it a radical shift in terms of architecture, design, deployment, features, and tools. The upgrade will be even more challenging if you decide to move from the forgiving VB compiler to the rigorous C# compiler. Confronted with declining vendor and community support and major migration challenges, BMW Financial Services in Dublin, Ohio, set out to define a strategy that would allow us to adopt C# in an efficient and deliberate manner. Our objectives were to minimize disruption and costs and leverage the momentum of the platform change to move our capabilities forward. This article presents our strategy and some of the experiences we are encountering along the way.

On the Road to .NET
BMW Financial Services is committed to Microsoft technologies and has used Visual Basic (VB) as the mainstay of application development for over 10 years. Their applications began taking shape in 1994, even as VB was still growing up. In early 2000, I was hired to manage the newly established system architecture team. We found ourselves facing a wide variety of architectures and coding styles. Although we are almost purely a VB shop, we had several different application frameworks and our code employed a number of different "standards" for common tasks. We also used over one hundred different third-party COM components. Our intent was to standardize our architectures and to implement more intelligent code reuse, but such changes are expensive, and building a case purely on the basis of architecture goodness is near impossible. By 2001, Microsoft had begun to promote its new, improved development platform - Microsoft's next-generation toolset that would become .NET. We decided that this new platform should become a key component of our standardization strategy. As luck would have it, in early 2002 we found ourselves at a crossroads: we were about to embark on a major CRM package implementation. The package warranty did not allow us to use stored procedures - the other mainstay of our application development. We would have to use the package's APIs. By now, .NET was entering the mainstream, particularly for developing middle tier Web services. It was a match made in heaven; we needed a solid platform for integrating with the CRM package, and .NET fit the bill perfectly. By the end of the year, we had used C# (See Sidebar: Choosing a.NET Language) to design, build, and deploy a service-oriented middle tier that integrated our legacy applications with the CRM solution. More importantly, we had also educated management about the impending loss of VB support and got the go ahead to build additional .NET frameworks that would form the foundation for migrating to .NET. (Sidebar 1)

We planned three application frameworks to help us migrate: one for desktop, one for Web, and one for batch jobs. We fondly refer to these frameworks as DesktopCAFE, WebCAFE, (CAFÉ stands for Common Application Framework for the Enterprise), and BEEF (Batch Environment Execution Framework). Each of these frameworks leverages .NET and the Microsoft Application Blocks / Enterprise library to provide architecture support for quickly assembling robust, modular applications. (Sidebar 2)

By the end of 2003, we had published the Batch Architecture Strategy and the WebCAFE adoption strategy, and had also deployed a very basic version of DesktopCAFE. Also in 2003, our service-oriented middle tier grew at frightening pace. In our haste to provide an easy-to-use service framework for the CRM project, we put very little governance around the creation of new services. This was both good and bad. On the up side, the C# middle tier provided a ready alternative to writing more VB. On the other hand, it was the only alternative, and we soon had a library of over 100 services of a questionable purpose.

VB Retirement Strategy
Our VB Retirement Strategy was a small document (26 pages) with several parts. It presented the case for VB retirement. It described the as-is and the to-be states of our processes and architectures. And it spelled out our guiding principles of .NET adoption. Most of the strategy was dedicated to describing the process improvements and other efforts that would be needed to ensure success. One of the most important aspects of the strategy was the set of guiding principles that would steer our decisions about .NET adoption. These principles are listed below:

• The effort will be gradual, spread across a three year timeline, and is scheduled to be complete prior to the Microsoft Visual Basic retirement date in March 2008.
• We will seek to minimize impact to business projects by aligning migration efforts with scheduled projects and avoiding code freezes.
• We will have a strong first year commitment to research and analysis so we can "get smarter" about the challenges up front and enjoy more predictable/efficient migrations in year two and three.
• We will attempt to leverage automated translation tools to the extent feasible.
• We will do a straight port of business logic, but allow structural changes in cases where technical incompatibilities exist or where we can move to common frameworks.
• Architecture/logic improvements can also occur if the cost of doing migration and project work together is lower than the cost of doing them separately.

The bulk of the strategy was dedicated to describing the five processes we would need in order to ensure a successful migration. Our mission would be to mature these five processes and use them to power the migration. These five processes are described here:

• Rearchitecting: This is implementing non-functional improvements to our systems. Our definition of rearchitecting is beyond the syntax changes and API replacements inherent in the VB-to-.NET translation. Rearchitecting is concerned with taking advantage of object-oriented principles, structured exception handling, and other .NET features. It also entails restructuring how the components and layers of the application interact with one another. New frameworks are a key aspect of the rearchitecting process. Another major aspect of rearchitecting is the implementation of transitional architectures that allows us to incrementally retire legacy architectures as we move to new ones.
• Translation: This is the most basic work of the migration: converting working VB projects to functionally equivalent, maintainable C# projects. Our existing code is the best specification we have for our systems because it's accurate, detailed, and has been tested in use. Translation allows us to leverage this asset. The translation process deals with defining detailed VB-to-C# conversion standards, tuning conversion tools, and developing refactoring techniques.
• Retooling: This is updating development processes and developer skills to work with .NET. The retooling effort is concerned with overcoming the challenges that mixed language development presents for our configuration management, build, and deployment procedures. Retooling also involves training developers and enforcing conversion standards.
• Testing: This is making sure the first three processes are working in a way that limits defects. Our organization has a streamlined quality culture: "we only test what has changed." This model does not scale very well when almost everything is changing. We are still coming to grips with this, and we are taking steps to ensure that quality is built into the conversion process up-front rather than expecting to test it in at the end.
• Managing: This is the work of coordinating technical teams, synergizing migration work with other projects, ensuring continuous improvements, monitoring progress, managing the budget, and removing obstacles.

These five processes interact to reduce the cost and increase the quality and speed of the .NET adoption effort. For example, an investment in translation capability will result in higher-quality C# code that is more correct and ready for rearchitecting. An investment in retooling will result in more repeatable translations, builds, and deployments, as well as smoother adoption of new architectures and tools. Rearchitecting will yield more complete specifications for translation and a solid target for migrated applications. Testing will ensure that other migration processes are working properly. Managing coordinates and balances these activities to make the most efficient use of program resources. Figure 1 shows how these processes relate to each other.

Estimating the Cost of VB Retirement
In addition to agreeing on a strategy, 2004 also saw us reach the more important .NET adoption milestones:

• We estimated costs and established a program budget for the next three years.
• We got buy-in from top-level management.
• We completed the implementation of WebCAFE and fleshed out the next versions of DesktopCAFE.