Migration Strategies

You should consider a number of factors when determining how to move your VBA applications to VSTO. First, it's a good idea to take an inventory of your VBA applications to judge their complexity and their dependencies. Does a given VBA application consist mainly of recorded macro code, or is it all high-end, handwritten VBA that uses features like UserForms, Web services, and native Windows API calls? The answer to this question will assist you in determining your migration strategy.

Next, inventory your skills. Do you have advanced VBA and Visual Basic knowledge, and do you understand the business problem that the VBA application is trying to solve? Part of the migration process is migrating your programming skills.

The easiest way to convert an application from VBA to VSTO is to convert the VBA syntax to Visual Basic syntax. This is the approach that you will take in the next section (refer to Chapter 4 to learn about the language differences between VBA and Visual Basic 2005). Converting syntax is easy for simple to moderately complex VBA projects, even if you have little knowledge of VBA or VSTO and little domain knowledge. Although this approach will get your VBA application converted, it will not take advantage of the features of VSTO. If you start with a poorly written VBA application, you will end with a poorly written VSTO application.

The next choice is to take a balanced approach. You convert much of your VBA code line by line, exploiting VSTO features where applicable. For example, in "Advanced Migration of a Word VBA Project" later in this chapter you will use an actions pane instead of a simple Windows Forms dialog box to collect user information. You could use XML nodes instead of bookmarks, and data caching instead of hidden worksheets. It requires more VSTO and domain knowledge to redesign the relevant parts of an application.

The most advanced way to migrate your VBA project is to completely redesign the entire solution. This approach requires the most VBA and VSTO knowledge and the most domain knowledge. The advantage is that you can focus on end-user goals, and you are not bound to the requirements that were specified when the application was originally written. User requirements change frequently, and redesigning the application gives you the opportunity to address many user needs. However, this approach is the most costly and time-consuming. Depending on the size or complexity of the application, you may want to purchase a third-party conversion tool to automate part of the conversion. You might also want to use interop to convert parts of the application in stages. This method allows you to incrementally add VSTO functionality to an existing VBA application.

Another advanced approach is to use VBA-to-VSTO interoperability, calling VSTO functions from VBA and calling your VBA functions from

VSTO. In this way, you can migrate your applications to VSTO in phases. For example, if you need to call a Web service, you can do it very easily in VSTO. But if your application uses a complex VBA macro, it might be easier to reuse it than to rewrite it.

Whichever approach you take, the benefits of moving to VSTO and managed code will pay off in the long term with increased developer productivity, quicker time to market, and advanced user features. However, if your VBA solution is working and meets your business requirements, you are not required to migrate the solution. VBA will be supported by Microsoft for the foreseeable future, giving you time to carefully plan your migration when it makes sense for your business.

0 0

Post a comment