Charteris White Paper

Moving from Visual Basic 6.0 to

.NET
Version 1.0
Gordon Mackie (gordon.mackie@charteris.com)
23 August 2004

2004 Charteris plc

1. INTRODUCTION 3
2. AN OVERVIEW OF .NET 4
2.1 What is .NET? 4
2.2 The .NET Framework 4
2.3 Developing in .NET 4
3. THE BUSINESS CASE FOR MIGRATION 5
3.1 “If it ain’t broke…” 5
3.2 Increased Productivity and Reduced Maintenance Costs 5
3.3 Increased supportability 5
3.4 Web enablement 5
3.5 Take advantage of the additional features of .NET 6
3.6 Adopt full Object-Orientation (OO) 6
4. KEY DECISIONS 8
4.1 The Main Decision 8
4.2 A Language of Choice 8
4.3 How to re-skill 9
4.4 Type of Migration – Porting and Re-factoring 9
5. PORTING TO THE .NET FRAMEWORK 10
5.1 Preparation 10
5.2 The VB Upgrade Wizard 10
5.3 Porting Manually 10
5.4 Target Language 10
5.5 Pros 11
5.6 Cons 11
6. RE-FACTORING WITH THE .NET FRAMEWORK 12
6.1 Preparation 12
6.2 Target Language 12
6.3 Pros 12
6.4 Cons 13
7. REAL WORLD MIGRATION 14
7.1 Migration Paths 14
8. MANAGING MIGRATION ACTIVITIES 16
8.1 Operational Considerations 16
8.2 Budgetary Constraints 16
8.3 Control and Boundary Definition 16
8.4 Technical Issues 16
9. CONCLUSIONS 17

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 2 of 17

Version 1.0 Charteris White Paper
1. INTRODUCTION
Many organisations have already adopted, or are currently considering adopting, the .NET Framework
as their platform of choice for strategic software development. One of the reasons often given for the
move is that use of the .NET Framework protects investment in existing software development
language skills such as Visual Basic and C++. The argument put forward is that if the NET
framework continues to support these programming languages then developers of new projects based
upon .NET will have a flying start through use of programming languages with which they are already
familiar. Likewise many consider it must be a fast-track for those moving old code to the new
platform as the same programming languages are used in both environments. However, in the real
world, new versions of languages and new platforms on which they are implemented, present
significant challenges to those adopting these newer technologies both for new development and for
migration of existing applications.
This Charteris White Paper examines some of the issues associated with migrating applications from
Microsoft Visual Basic 6.0 (VB6.0), and earlier versions of COM-based Visual Basic, to Microsoft
.NET languages including Visual Basic .NET (VB.NET). It examines the options for migration and
offers some guidelines on best practices that can help organisations to successfully migrate their
applications to the .NET world.
For clarity in this document, we make the distinction between the concepts of porting and re-factoring in
discussing the process of migrating software applications. We define porting as the process of taking
COM-based VB 6.0 or earlier code and converting it to .NET code without changing the basic
architecture or design. We define re-factoring as re-working a software solution in the process of moving
it from COM-based VB 6.0 or earlier code to .NET code such that its feature set and functionality are
retained, but that its internal implementation may be significantly different. In later sections we look at
the issues involved both in porting code and in re-factoring solutions.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 3 of 17

Version 1.0 Charteris White Paper
2. AN OVERVIEW OF .NET
2.1 What is .NET?
Microsoft defines .NET as “a set of Microsoft software technologies for connecting information, people, systems, and
devices. It enables a high level of software integration through the use of Web services—small, discrete, building-block
applications that connect to each other as well as to other, larger applications over the Internet.”
Whilst Microsoft has in the past sought to brand (and re-brand) much of their software product set
under the general umbrella of .NET, the true newer technologies that constitute .NET as far as the
software development community is concerned are:
♦ The .NET Framework, which is used for building and running all kinds of software, including
Web-based applications, smart client applications, and XML Web services.
♦ Developer tools, such as Microsoft Visual Studio® .NET 2003 which provides an Integrated
Development Environment (IDE) for maximizing developer productivity with the .NET
Framework.
2.2 The .NET Framework
The .NET Framework is an integral Windows component for building and running the next
generation of software applications and Web services. The .NET Framework:
♦ Supports over 20 different programming languages – with 4 core languages supplied by Microsoft
namely C#.NET, VB.NET, C++ .NET and J#.NET.
♦ Manages much of the plumbing involved in developing software, enabling developers to focus on
the code associated with the core business logic.
♦ Makes it easier than ever before to build, deploy, and administer secure, robust, and high-
performing applications.
The .NET Framework is composed of the Common Language Runtime (CLR) and a unified set of
class libraries.
2.3 Developing in .NET
Developers can use the .NET language of their choice for code creation and debugging. When
compiled with a language specific compiler in the .NET Framework, the language-specific code gets
translated into language-neutral and CPU-independent Microsoft Intermediate Language (MSIL).
Before this code can be run, it must be converted by the .NET CLR to CPU-specific code; which is
usually done by a just-in-time (JIT) compiler converting MSIL to native code only when actually
required.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 4 of 17

Version 1.0 Charteris White Paper
3. THE BUSINESS CASE FOR MIGRATION
3.1 “If it ain’t broke…”
Whilst adopting .NET as a platform for new development projects can be seen as a relatively
straightforward strategic decision on the part of an enterprise, the migration of existing applications to
the .NET environment might be seen as a more questionable one. Systems that have already been
developed and implemented using tools and technologies from the world of COM and which are
performing their functions quite satisfactorily do not necessarily have to be moved to the .NET world.
The old adage that: “if it ain’t broke, don’t fix it” could quite easily apply were it not for some
arguments for migration that in many cases are compelling. The following sections examine these.
3.2 Increased Productivity and Reduced Maintenance Costs
Probably the biggest advantage offered by .NET is that much of the code that would previously have
had to have been written on a bespoke basis can now be considered as “part of the plumbing”
provided by .NET. No longer does the programmer need to write a mass of code to cope with, for
example, memory management and garbage collection but instead s/he can focus their skills on
developing business logic to meet the business need. The impact of this is that programmers are
typically far more productive in delivering finished product.
The corollary of having the development team focus on producing code focussed on the core business
logic is that there is less code to go wrong: the infrastructure provided by .NET has been tested and is
supported by Microsoft and hence is not going to need to expensive attention usually required for
bespoke code.
As .NET is still relatively new the skill base is still growing and hence there is a premium on hiring
people with .NET skills. However, over time more and more developers will become skilled in the
.NET languages such as VB.NET and C#.NET. After taking the costs associated with using one-off
conversion tools in to consideration, the cost of skilled resource to perform development and
maintenance tasks will soon correspond to that for the older environments. When combined with the
increased productivity and the reduced maintenance costs the overall cost advantage in using .NET is
significant.
3.3 Increased supportability
There is a risk in not adopting .NET. As .NET has gained significant momentum in the development
community there will be fewer and fewer developers available with the skills or inclination to work
with older languages. This will mean that writing code for new applications or maintaining older ones
in the older codebases, will become more expensive and harder to resource.
This risk is compounded by the fact that Microsoft will ramp down support for VB6.0 in 2005. So
migrating to .NET will reduce the risk of being dependent upon a disappearing Microsoft product
support structure. With progressively fewer developers available to support VB6.0 applications in the
future, migrating to .NET means that business-critical applications will continue to enjoy support for
the underlying technologies from Microsoft.
One could argue that the same may happen to .NET as is now happening to VB6.0. However, this is
unlikely as Microsoft have already announced that the roadmap for the next generation of their
operating systems (codenamed Longhorn) will have an integral component - WinFX, which will extend
V2.0 of the .NET Framework incorporated in Visual Studio 2005 (due to be released next year),
adding APIs for a new graphical user interface subsystem (Avalon), a new file subsystem (WinFS) and
a new Web Services messaging subsystem (Indigo). Hence, one can be confident that the approach to
future developments is more one of evolution rather than the distinct shift that we have seen with the
introduction of .NET.
3.4 Web enablement
Although web development was, and is, possible using the COM-based technologies in VB6.0 and
earlier versions of Visual Basic, such capabilities were add-ons to the core functionality and not built-in

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 5 of 17

Version 1.0 Charteris White Paper
to the heart of their structure and operation. In contrast, the .NET Framework is oriented very much
towards using the internet and its associated messaging protocols as the preferred way of developing
and integrating applications.
The .NET Framework is essentially designed bottom-up to support fast-emerging standards such as
the Simple Object Access Protocol (SOAP) which allow applications to communicate with each other
across networks and the internet using XML Web Services. Migrating to the .NET Framework means
that these standards can be embedded by default into the applications that organisations write,
increasing their ability to communicate with external applications.
3.5 Take advantage of the additional features of .NET
There are many key benefits and improvements that the .NET Framework provides over VB6.0, these
include:
♦ Stability – .NET is not prone to the memory leak problems often encountered in the COM
world. Because the .NET Framework is type-safe and uses the in-built Garbage Collector to
reclaim memory, memory allocation and release is no longer the responsibility of the applications
developer, nor of the developers of any libraries s/he uses. Additionally, the .NET assemblies have
greater control over mutual component-compatibility levels eliminating many problems with
deployed libraries of mismatched versions.
♦ Better organisation – The Framework Class Libraries offer a well structured and documented set
of features, organised into logical namespaces. These are accessible to all .NET languages and
provide a better coding model than that of older Visual Basic versions with their inconsistent use
of keywords, object-references and API declarations to extend and enhance language functionality.
Developers can take advantage of namespaces too, for organisation and logical grouping of their
own code.
♦ Better inline documentation – In C# .NET, XML documentation offers the ability to add rich
code annotation that can be used to generate help documentation and intellisense for code
artefacts. VB.NET will have XML documentation in the next release of Visual Studio (Visual
Studio.NET 2005) and third-party add-ins are available that emulate it in the current version.
♦ New features – The Framework Class Libraries offer a much richer set of features, with extensive
support for data access (in ADO.NET), XML, cryptography, security and much more besides.
♦ Security – The memory that a piece of code can access has more restrictions and is controlled by
the CLR, thus making malicious memory accesses more difficult. The CLR also has a
comprehensive security model which is integrated into the operating system making it possible to
do things like prohibiting unapproved code from executing.
♦ Deployment and Management – .NET allows applications to be deployed in a choice of ways
and has better features for build & deployment, version management and application
configuration.
3.6 Adopt full Object-Orientation (OO)
C#.NET and VB.NET are both fully Object-Oriented languages with many powerful Object-
Orientation features that give them the advantage over the “Object-based” VB6.0 and even the .NET-
compliant, but non-OO languages. A non-OO legacy language such as COBOL is not as functionally
rich as VB.NET or C#.NET and so migrating an application written in that language to an Object-
Oriented .NET language may offer scope for extension and improvement along Object-Orientation
lines whereas this would have been impossible to do by maintaining the application in the legacy (albeit
.NET-compliant) language.
Adopting an Object-Oriented language therefore allows the utilization of associated Object-
Orientation design principles and developing code that has been designed with the principles of
Object-Orientation in mind means that the code is more likely to be reusable. This in turn reduces
development costs and means that code that is developed in this modular fashion is much easier to

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 6 of 17

Version 1.0 Charteris White Paper
maintain over time. It is not unknown for 65%+ of “boiler plate” code to be eliminated when armed
with all the Object-Orientation features of the .NET Framework.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 7 of 17

Version 1.0 Charteris White Paper
4. KEY DECISIONS
4.1 The Main Decision
Notwithstanding all the above arguments for migration, an organisation may still decide that it is happy
to leave its stable and working COM/VB applications as they are. However, assuming that an
organisation is convinced of the business case for migration and wishes to adopt the .NET
Framework, there are a number of further key decisions to be made in order to progress. The
following sections consider these.
4.2 A Language of Choice
An organisation that has decided to migrate an application or set of applications to the .NET
Framework will probably want to decide on a single .NET language as the preferred language for all
code produced. Despite the fact that all .NET languages are considered equal, can be freely mixed and
interoperate easily, it makes sense to standardise on a single language in order to minimise training and
support costs and to maximise the effectiveness of developers in maintaining and extending .NET
codebases.
For an organisation with a strong investment in VB skills, the selection of VB.NET as language of
choice would seem to be an obvious one. Developers familiar with the Visual Basic language in its
COM incarnation will recognise almost all the elements of the language in its VB.NET guise. Despite
this, many organisations with a large VB codebase and communities of experienced VB developers
give serious consideration to adopting C#.NET as their language of choice when moving to the .NET
platform.
Some of the reasons for this are matters of preference or perception whilst others lie in the fact that
although VB.NET now provides support for full Object-Orientation and offers stricter type
enforcement than VB did in the past, it does not actually enforce their use. What is more VB.NET
continues to provide implicit conversions behind the scenes in the name of ease of use which many
developers see as a deficiency and potentially dangerous. Consider the following VB.NET code:
Dim evaluateString As String
If evaluateString Is Nothing Then
Console.WriteLine("evaluateString is Nothing")
End If
If evaluateString = "" Then
Console.WriteLine("evaluateString is an empty string")
End If
Ambiguously, even with Option Strict On, both tests in the above code will evaluate as true.
In addition to strong type enforcement, C#.NET benefits from several compile-time code-checking
features. For example, C# code that attempts to access un-initialised variables, code that never uses a
variable, (initialised or not), or code that is unreachable will all generate errors or warnings from the
compiler. In comparison, VB.NET silently compiles this kind of code making it potentially more
prone to errors.
More subjectively, many developers see C#.NET, C++.NET and J#.NET as more syntactically
elegant languages and in comparison find VB.NET syntax ugly and cumbersome. Whilst this may be a
matter of personal taste, it can also be seen as indicative of a more general perception of VB.NET as
the less “serious” programming language. Certainly the language enhancements planned for the next
release of the .NET Framework would seem to reinforce this perception, with VB.NET language
enhancements aimed at making code development easier and C#.NET enhancements aimed at making
the language richer and more powerful.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 8 of 17

Version 1.0 Charteris White Paper
So does that make a convincing case for abandoning VB in the migration to .NET? Well not
necessarily. There are other considerations to be taken account of, not least the comfort and
familiarity factors of moving from VB6.0 to VB.NET and the preservation of existing training
investment made by an organisation in the VB language. At Charteris we have adopted C#.NET as
our language of choice and much of Microsoft’s own code development is now done in the language,
but an organisation’s choice of .NET platform language must be based on its own circumstances,
requirements and existing investment in developers and training.
4.3 How to re-skill
It is normally the case that an application developed in VB6.0 or an earlier version will be supported by
some or all of those developers who produced the original code. And it is also normally the case that
when the time comes, these same developers will be the team charged with migrating the application to
.NET. This makes sense since they are the ones with the understanding and domain knowledge
required to do it.
However, if these domain experts are new to .NET or are unfamiliar with Object-Orientation (OO)
design principles, problems may be experienced when attempting to migrate to the .NET Framework
from the merely Object-Centric world of earlier versions of Visual Basic. Opportunities to take
advantage of .NET features may be missed, there may be the temptation to bring ‘bad habits’ from the
old VB world and impose them on the .NET world or developers may not know where to find useful
implementations of standard functionality implemented in the Framework Class Libraries and waste
time producing their own unnecessary code.
It is therefore critical that an organisation takes into consideration the skills of their developers and the
budget available to retrain them when choosing how to migrate to the .NET Framework. Where
necessary, putting in place experts to help mentor existing staff is an extremely effective way of seeding
the required skills into an organisation. This mentoring can help steer migrating developers down the
right paths in adopting good practices and coding discipline for the .NET world.
4.4 Type of Migration – Porting and Re-factoring
Once an organisation has taken the decision to move its legacy code to the .NET Framework, it must
decide on its approach to the process. Although individual cases will vary and in most cases a blended
approach will be inevitable, the two broad approaches that can be taken are porting and re-factoring.
An organisation can essentially choose either to port the code into the .NET Framework without
making any changes to the underlying solution design or to completely re-design the legacy solution
and implement it in the .NET Framework.
A port, as the name suggests, is an attempt at a direct line for line re-write, replicating the internal
architecture and implementation of the solution and producing the same functionality and features.
The appeal of taking this approach is the promise of a quick, automated (as far as possible), low
resource (development, test, etc.) conversion.
Re-factoring does not attempt to convert the existing code but rather takes the current logical and
architectural design as a starting point for reworking the solution with Object-Orientation and the
.NET Framework in mind. This ultimately leads to a new design which is then implemented in new
code. The appeal of this approach is its promise of producing a better, Object Oriented and .NET-
centric, design and codebase that can form the basis of future extension and enhancement.
The next section examines each of these approaches in more detail and looks at the pros and cons
associated with them.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 9 of 17

Version 1.0 Charteris White Paper
5. PORTING TO THE .NET FRAMEWORK
5.1 Preparation
Preparatory work for porting concentrates on assessing the suitability of the codebase for porting and
on identifying problem areas where 1-for-1 code conversion will not be possible – for example in the
case of old VB “OnError-GoTo” style error handling. These situations will require intervention with
some redesign and code rework and examining the codebase from this perspective allows an
assessment the level of the rework likely and may suggest that the re-factoring approach would
ultimately require less effort than the port.
In the process of assessing the codebase there may be an opportunity to prepare it for processing by
the VB Upgrade Wizard. Very often large existing VB projects have macro utilities to manage the
creation and insertion of standard code constructs such as error-handling and logging. It may be
possible to leverage these in order to remove or alter code before it is upgraded to reduce the time it
takes to process the code and reduce the size of the issue report it produces.
5.2 The VB Upgrade Wizard
Microsoft Visual Studio .NET offers a VB upgrade wizard to assist in the migration of earlier VB code
to VB.NET. This tool attempts to convert code from VB to VB.NET, provides an upgrade report
listing any problems encountered and annotates the converted code with comments on conversion
issues and recommendations. It also inserts To Do items into the Visual Studio Task List indicating
where additional changes need to be made. Some older VB constructs and concepts that cannot be
converted to VB.NET, for example control arrays, may be retained and supported by implementation
of calls to VB6.0 compatibility COM libraries through wrapper .NET classes. This is the most basic
port requiring the least time and effort to complete.
There currently is no upgrade wizard for upgrading VB6.0 code directly to C#.NET.
5.3 Porting Manually
In the cases where developers responsible for porting code do not want to use the VB Upgrade
Wizard, (or cannot use it because they are not migrating to VB.NET), the only alternative is to port the
code manually. Code must be examined line-by-line and converted to a .NET equivalent
implementation where possible and any unavoidable workarounds hand-coded to suit the particular
circumstances and requirements of the code being converted. Whereas the VB Upgrade Wizard might
make calls to VB compatibility DLLs as a result of code ambiguities that it has problems interpreting
or take the ‘path of least resistance’ in converting, the porting developer may be able to make better
choices in these circumstances eliminating or at least reducing the need to retain a reliance on “old
VB”.
5.4 Target Language
Whilst the factors affecting the choice of .NET language have already been discussed earlier in this
document it is worth revisiting the topic of the choice of .NET language again here with particular
regard to porting applications.
At Charteris our experience has shown that the effort involved in porting applications from VB6.0
does not vary greatly with the choice of target .NET language. We have found that the majority of the
migration effort lies in the selection of the appropriate .NET Framework Class Library functionality
and its use in code rather than in the mechanics of changing or adapting code syntax per se. In terms
of porting at least, this makes the option of converting from VB6.0 to VB.NET (using the Upgrade
Wizard if required) and then on to C#.NET at a later date, a viable option. We have found that making
syntax changes going from VB.NET code to C#.NET code is often negligible when compared with
the time taken by developers learning the .NET Framework Class Libraries and adapting code to use
them.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 10 of 17

Version 1.0 Charteris White Paper
5.5 Pros
The VB Upgrade Wizard provides a quick and largely automated route to porting code leaving the
developer to fix the aspects that cannot be ported automatically using the advice and guidance
provided by the report produced as part of the upgrade process.
The leg-work of repetitive code conversion can safely be left to the tested functionality of the wizard
whilst the coder can concentrate on the ‘tricky’ bits.
In theory assessing code for line-by-line porting has less dependence on a need for a strongly
documented design of the existing system – as the structure will not change there is less emphasis on
understanding of the design than on understanding of VB and COM fundamentals such as finalisation
and data access.
In principle the code produced will require less testing and review because of its closeness to the
original codebase and the fact that much of the ported code continues to use VB compatibility DLLs
means that the emphasis is on safety and workability.
5.6 Cons
The VB Upgrade Wizard necessarily takes the path that is safest and the one of least resistance which
is unlikely to be the most efficient or logical. For example, retaining the use of ADO libraries through
interoperability is considerably less efficient than changing code to make use of ADO.NET. The
resulting codebase produced by the wizard is almost always a hybrid of .NET code and calls to VB
compatibility libraries, making the move to .NET a nominal one to a large extent.
Whether arrived at via the Upgrade Wizard or through manual porting, the introduction of a
dependency on COM interoperability and older VB libraries may hamper future efforts to move the
codebase further into the .NET world when the time comes for extending and enhancing the
applications created. Additionally the reliance of older VB6.0 libraries introduces a risk for code
support relying as it does on their continued support by Microsoft.
Many of the business case drivers identified in our examination of the case for migration are not
addressed by porting code: its essential internal structure and architecture remain the same meaning
that its supportability, maintainability and overall code quality are not improved; and mechanically
converting code by porting does not offer the opportunity to take advantage of .NET’s new features
such as better web enablement or support for Object-Orientation.
Many have found that a porting exercise that retains a large amount of, and reliance on, COM
interoperability and compatibility libraries represents a poor return on investment.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 11 of 17

Version 1.0 Charteris White Paper
6. RE-FACTORING WITH THE .NET FRAMEWORK
6.1 Preparation
Re-factoring an application involves a much greater understanding of its design and implementation
than would be required to port it. In preparing for a re-factoring migration it is important to make
sure that the system is well documented with an up-to-date specification and set of design
documentation. It is obviously preferable that this design documentation exists already as collateral
from the original design and implementation of the system. However, in the real world, preparation
work for re-factoring may require system analysis and documentation for systems where it doesn’t
already exist or is no longer as built due to documentation not being synchronised with post
development enhancements.
One of the goals in redesigning a VB6.0 solution and re-implementing it in the .NET Framework, is to
realise the benefits of Object-Orientation such as code reuse and more efficient structure. In order to
do this the system must be comprehensively understood and redesigned using Object-Orientation
principles. This analysis and design preparation obviously represents a greater short term cost and
effort than that associated with porting but carries the potential of realising much greater long term
benefits.
In addition to a good understanding of the existing system, re-factoring requires expertise in Object-
Orientation design and best practice. Where an organisation does not have these skills in-house it will
have to recruit people with these skills, retrain existing staff or identify short-term contract resource to
provide them.
Where the scope of the work includes the introduction of new functionality or a fundamental design
change a targeted re-design from the bottom up is likely be the most appropriate approach. However,
as with any project, if new functionality is being introduced it obviously needs to be managed carefully
with a clear statement of requirements and definition of the required additional functionality.
6.2 Target Language
Whilst in the case of porting, the availability of the VB Upgrade Wizard might be seen as a reason for
sticking with a form of the Visual Basic syntax (at least for the process of migration), there is no such
attachment to VB in the case of re-factoring. As the system will be re-implemented in new code the
slate is effectively clean and the choice of target language can be made with a consideration of other
factors such as an organisation’s general strategy for .NET, and a view to the longer term directions
that .NET languages might take.
6.3 Pros
Re-factoring is a chance to make a break from the older world of VB and COM and realise the benefits
of re-designing and implementing systems to take advantage of Object-Orientation and newer
technologies such as the internet and XML.
The goals of better supportability and maintainability through better design and code-quality can be
achieved without the constraints and potential future liabilities of retaining dependence on
interoperability and legacy COM and VB DLLs.
Re-factoring also represents a chance to take a pattern-based approach to re-design and
implementation that wouldn’t be possible with porting – common solutions to common design
scenarios can be approached in terms of existing documented patterns and implemented in reusable
modules that can be applied across the system for common needs such as data-access, message
management, error & activity logging and so on. This offers benefits in terms of speed of design,
reusability, supportability and testing.
The bad practices of the past that might have been forced upon developers by the limitations of VB6.0
and earlier can be left behind and the freedom to exploit the Object-Orientation offered by .NET
languages fully embraced.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 12 of 17

Version 1.0 Charteris White Paper
6.4 Cons
The goal of escaping the world of COM and older VB may not be fully realisable if the re-factored
systems still have to rely on services not currently available through .NET such as distributed
transaction support or where the systems must make use of third-party integration components that
are COM based – many of Microsoft’s own products are yet to be .NET-enabled and still rely on
COM interfaces for integration and automation – Microsoft Office for example.
Acquiring or developing Object-Orientation skills and .NET expertise can represent a considerable
short term cost and introduce project “ramp-up” delays that an organisation may not be able or willing
to accept in return for promised longer term benefits.
With an effective re-design of a system there will be the temptation to take advantage of the situation
to introduce new functionality. Many organisations will build wish-lists of future requirement requests
between application releases and the option to roll these features into a re-factoring migration may be
appealing. Whilst there may be very good sense in taking advantage of this opportunity and some very
easy “wins” to be gained at very little extra expense and effort, there is a danger that without proper
control the situation could turn into a free-for-all with everything being “up-for-grabs”.
Re-factoring systems may give rise to problems with interactions, dependencies and interfaces to other
systems that are not being migrated at all or are being ported rather than re-factored. There is a
potential “domino-effect” of changes in re-factored systems’ interfaces or behaviours forcing change
on systems outside the boundaries of the re-factoring efforts. In these cases the external systems may
prove to be immutable forcing compromise or further work on the re-factored systems to
accommodate the constraints that the external systems represent. At the very least problems may be
encountered in defining and maintaining system-boundaries in order that the scope of the re-factoring
does not creep into other systems and impose extra re-work and consequent cost upon them.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 13 of 17

Version 1.0 Charteris White Paper
7. REAL WORLD MIGRATION
7.1 Migration Paths
As stated before, in the real world an actual migration activity for a system is likely to involve a
combination or blend of the porting and re-factoring approaches. The following section describes the
paths available through migrating an application and the options for applying porting and re-factoring
techniques at the various stages in the process.

Decide on porting extent

Modify VB6 code.

(exception handling etc.)

Use the built-in conversion 1 Completed:- limited port

tool to transfer code. using VB6 libraries in .NET

Use conversion tools to

re-work libraries
create C# code.

Completed:- VB.NET port Completed:- C# port using

2 3
using .NET libraries .NET libararies.

In the above example of a Visual Basic migration path there are three possible exit points from the
process:
1. Here the migration activity ends after the most basic of porting activities using the VB
Upgrade Wizard after any (optional) preparatory parsing of the codebase for efficient
processing by the wizard. It is the fastest and least demanding of approaches but carries many
of the risks described in section 5.6 above.
2. Here a fuller port is carried out beginning the process above followed by a second stage of
converting all library calls to use the .NET Framework instead of using the backwards
compatibility libraries; this represents a significant amount of work and needs to be done
manually by skilled .NET developers. The advantage here is that the target language is
VB.NET where the keywords are familiar; all the Framework calls are however, new.
3. Here a further stage is added after the two above, to convert the syntax to C#.NET. This
allows the organisation to adopt C# as its language of choice if it desires and does not add
significant overhead since the majority of the migration effort will occur at stage 2 above, in
changing the library calls into the .NET Framework. Additionally, the mechanistic nature of
converting VB.NET syntax to C#.NET syntax allows for the use of either in-house developed
macros or the use of third-party tools to automate all or a large part of the process. Whilst
these tools are not 100% effective and creating or obtaining them may represent an additional

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 14 of 17

Version 1.0 Charteris White Paper
 cost, they may prove cost effective in getting the last part of the way to moving legacy VB
applications to a C# .NET codebase. For examples of the possibilities available for such
automation see The Code Project (http://www.codeproject.com/csharp/GBVB.asp) and
ELLKAY (http://www.ellkay.com/ConvertVB2CSharp.htm).

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 15 of 17

Version 1.0 Charteris White Paper
8. MANAGING MIGRATION ACTIVITIES
8.1 Operational Considerations
Here we discuss some of the control and management issues around migration that affect the
successful migration of systems to .NET.
8.2 Budgetary Constraints
A key factor when considering approaches to migration is likely to be cost constraint. Re-factoring is
by nature a longer and more costly process than porting and decisions to concentrate on one over the
other and to vary the ratio between them in a blended solution will be affected by budget
considerations. Re-factoring also brings associated risks that costs may escalate through scope-creep
and the effect of re-design and re-work on other systems. Strict definition and management of scope
and impact on other systems can mitigate these, but re-factoring will always remain more expensive
and time-consuming than porting.
8.3 Control and Boundary Definition
As mentioned before, often systems that are being migrated will have to co-exist and interoperate with
others that cannot be migrated and cannot change their interfaces. Identifying these systems early and
planning for the impact of accommodating them is essential. Taking a consistent approach to
interfacing to them and having the interfaces defined from the outset will aid control and containment
of the effort required to interact with them.
If these interfaces are common ones that other migrating systems will also use then a consistent
approach will allow reuse of interoperability code modules and a common approach to interacting with
them that will pay dividends in development and test effort.
8.4 Technical Issues
The move from the COM world to the .NET world presents some large architectural shifts that have
an impact on both porting and re-factoring activities; the move from a reference-counted
object/memory management model to a garbage-collected one presents situations where some re-
factoring is inescapable. In these cases a porting approach must be managed to ensure that re-factoring
is limited to unavoidable re-work and does not widen its scope to include a more general re-factoring
with resulting increase in cost and timescales.
Whether porting or re-factoring, the move to the .NET work does not automatically bring the
technology benefits of its richer feature set. Control and enforcement of good practices through team-
leading and mentoring by experienced .NET professionals can avoid unnecessary and ill-advised
replication of code-solutions and deprecated practices developed in the VB/COM world and can
ensure that good Object-Orientation principles are adopted.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 16 of 17

Version 1.0 Charteris White Paper
9. CONCLUSIONS
It is clear that the move from VB to .NET is not a simple matter of running a one-off conversion tool
(if it were the process would not be a matter of discussion). Many factors affect the approach, a great
many of which are not technical.
It is not possible to say in general whether opting for porting or for re-factoring is most appropriate
without assessing individual migration projects in the light of the strengths and weaknesses of each
approach. In most cases the combined business/technical factors will force a blend of approaches to
be adopted.
Additionally an organisation must ask itself why it is considering migration and what it hopes to
achieve from the process. Taking a simple and least disruptive approach may not yield many benefits
over leaving applications un-migrated, but could potentially allow access to important features only
available through .NET. Engaging in a full re-factoring exercise may leave an organisation with a well-
designed and structured codebase ready for further enhancement and reuse (through new delivery
channels and integration with other .NET developed systems), but may incur unexpected costs and
impact much more than the systems being migrated.
The process should not be undertaken lightly and its management and control are key to successfully
moving to the .NET environment and enjoying the benefits of Microsoft’s newer technology.

7 September 2004 Moving from Visual Basic 6.0 to .NET Page 17 of 17

Version 1.0 Charteris White Paper