From obsolescence to efficiency
Migrating from VB6 to VB.NET in a cost-effective manner How to reduce financial pressures and risks while modernizing your IT system
Summary Few businesses have been immune from the effects of the economic downturn. Cost cutting is essential, but firms still need to invest in critical areas to remain viable. IT is one such area: though IT directors are being charged with doing more with less resources and are scrambling to streamline their application development processes. With so many firms using Microsoft Visual Basic 6.0 (VB6) as their primary development environment, the difficulty in achieving flexibility and cost-effectiveness has been intensified by Microsoft’s termination of support for VB6. According to the Aberdeen Group1 the top pressures forcing migration from VB6 to VB.NET are the need to build out and improve current technology (53%), company policy to migrate away from unsupported development languages (34%), the need to streamline the development process (26%), lack of scalability in the current development environment (23%), and the need to integrate with industry standard applications (19%). Three options exist: 1) continue working with an unsupported development platform, 2) replace VB6 with a package implementation or re-development, or 3) migrate the existing VB6 software to Visual Basic.NET (VB.NET) and modernize applications once this has been achieved. Some resource-heavy organizations have the internal horsepower and domain expertise to manage the migration. Many others will offload the burden to an IT service provider or consulting service. The desire to reduce IT operating costs (and speed up the implementation) are the primary reasons given for outsourcing such IT functions. Whether the migration/modernization is done in-house or outsourced, failure to plan effectively can be devastating to an organization’s viability. This paper reviews the current migration and modernization solutions for converting valuable software assets from the VB6 platform, as well as 12 tips for handling the migration.
Aberdeen Group, “Migrating from VB6 to .NET: The Challenge of Software Agility in a Volatile Economy”, Analyst Insight, April, 2009 1
Organizations in transition Organizations are addressing the new economic realities and other challenges by implementing new business models. As a result, expectations have never been higher for the role of information technology (IT) in improving the customer relationship and increasing internal efficiencies. While advances are being made on many fronts, some rather formidable challenges remain. All organizations must create strategic plans on how to utilize and share information with stakeholders. Microsoft Visual Basic has had many evolutions since its original release, Visual Basic 1.0. Companies currently using VB6 for application development are faced with the challenge of moving away from a platform that, as of March, 2008, is no longer supported by Microsoft. The recommended upgrade path is to Microsoft’s .NET Framework. The release of VB.NET is the biggest evolution yet. The language has been redesigned to take advantage of the .NET Framework. VB.NET totally integrates with the .NET Framework and makes it easier to write distributed applications such as Web and enterprise n-tier systems. Migrating from VB to VB.NET allows companies to move into a fullysupported and updated development environment. The decision to migrate from VB6 to VB.NET should be based upon a strategic business assessment. One option that is available is to use automated migration software tools to help move applications into Microsoft’s .NET Framework. Microsoft ships the Visual Basic Upgrade Wizard with all versions of Visual Studio .NET. Third-party software such as ArtinSoft’s VB Upgrade Companion and Code Architects’ VB Migration Partner offer solutions with a proven record of successful migration projects. Even with the help of these VB to VB.NET migration tools, it is still necessary to plan the migration project in order to ensure its success. The principles behind modernization are based on the optimum retention of existing business logic and data (from the legacy systems) combined with the marriage of new capabilities. Regardless of the option chosen, unless business processes have changed significantly, the minimum requirement of the new solution is that it does all the things the existing application does. Otherwise, the legacy application can never be turned off.
Process-oriented planning, tool-based implementation The decisions involved in migration and modernization not only include the obvious (which applications, which platform, budget, timeline, etc.), but also need to consider all the other facets -- not simply the code conversion. These decisions are best supported by using a processoriented approach for the planning. Some of the most experienced modernization vendors have developed and refined the process steps and offer specialist services to assist organizations. In general, the steps include:
1. Evaluate the business fit It is important to understand the value of existing application assets to the business, the need for strategic investment, and the current total cost of ownership of each system before a clear modernization strategy can be determined. Many legacy applications, although rich in functionality, are difficult to modify, are less integrated with other systems and cost disproportionately more to operate. Additionally, if the application operates on a proprietary hardware platform this may be considered as an operational risk. Kaplan & Norton2 have developed a Strategic Readiness concept to evaluate how readily an application can support the crucial business processes required to achieve the organization’s strategic objectives. Applications are evaluated on how well can they support the processes now, and when will they be available to give the required support. Some applications will be deemed “ready” in the right form and with the required infrastructure. Others will be deemed “almost ready” depending on how much time and effort is required to make them available. Others will be evaluated as “not ready.” Legacy applications that fall into these last two categories must be modernized. In a world of unlimited capital and unlimited time, the assumed best solution might be to start over – creating a new IT architecture with new hardware and software. But, this is the modern equivalent to “throwing out the baby with the bathwater.” With capital at a premium, current thinking is to modernize existing legacy IT systems to handle the new demands. This way, the “baby” is retained and enhanced by new technologies on open system platforms.
Kaplan & Norton, “Measuring the Strategic Readiness of Intangible Assets”, HBR, February, 2004 2
2. Define the target environment If the recommendation is to move a legacy application off its current platform to a modern environment, more than hardware is involved. An assessment of operating system, languages, user interface, database required, third party products required, and how the application interfaces with other systems must be made. There are many issues to be defined: What will the architectural framework be? How readable and maintainable will the resultant converted code be? Does the organization possess the required skills? etc. Code conversion, particularly from a procedural language to an object-oriented language, is unlikely to be a fully automated process.
3. Create a migration strategy and prioritize actions There is often the temptation to attempt to do everything at once during a migration: change platforms, change user interfaces, change databases, improve integration with other applications, etc. The most successful projects are those that prioritize these activities and break them up into sub-projects in a way that each sub-projects can be delivered separately. The project scope must be documented in detail beforehand. This ensures that the strategy, tactics, and resources have been agreed upon and “scope creep” is eliminated, or at least minimized. The activation of a formal change request procedure, where implications are signed off by all project owners, reinforces this discipline. The project plan is typically a team effort: drawn up in close cooperating with the vendor(s) and key internal personnel. Most project plans consist of at least four parts:
Desired outcome (end-state objectives) Budget requirements Timeline showing project tasks and required resources to complete the task. Ensure that sufficient time is allocated for testing and at the end of each major milestone build in a small contingency. Detailed commentary on the tasks and responsibilities for the organization and the vendor(s). It should include the scope of the project, the success criteria, detailed steps of each project phase; the number of test cases the vendor is to carry out for each work package; final acceptance testing, and the acceptance criteria. It should also articulate how the project will be monitored and the project change procedures. Lastly, it is important to document what is not included in the project scope.
4. Investigate modernization products and services With a Roadmap and detailed project scope in hand, the next step is to investigate the technologies and services available to best implement the project. Has a project similar to the one in your scope been done before, or is this project unique? What experience do vendors have in this area? Are there automated tools to assist? Modernization projects typically start off with very simple ideals, such as replacing a flat file system with a relational database. However, the choice of tools to achieve this can vary from replacing all of the existing I/O statements with embedded SQL (which is a time-consuming, laborintensive approach) to a middleware solution that is virtually risk-free, faster, and less expensive. Middleware tools differ in their architecture and it is vital to investigate them fully to ensure that the chosen solution will provide the performance and scalability required. These tools can handle VB6 project groups as well as constructs that have no direct equivalent in the .NET Framework world, correctly converting language constructs that are commonly considered as impossible to migrate automatically. The tools can be customized and fine-tuned to tell the migration engine how code should be handled during the conversion step.
5. Allocate resources People, money, time. Those are the resources required. Most projects require a mixture of internal and external vendor resources. Internally, the key position is that of Project Manager (PM), who has overall responsibility for project success. Success is measured in terms of meeting all the project targets for effectiveness, budget, and schedule. In addition to coordinating and communicating with the equivalent PMs from the vendor side, it is the responsibility of the PM to ensure that the relevant application assets, the test plans, testers, and other resources are available when required. Project execution not only requires technical skills, but also interpersonal skills to coordinate, communicate, and motivate the project team. It is essential that project managers keep on top of the tasks, particularly at the beginning. Quite often, internal staff continue to give priority to their “day jobs,” rather than focusing on project tasks. “Schedule creep” at the beginning too often leads to missing the deployment date at the end, unless considerable contingencies are built-in.
The team that is required to achieve a successful VB to .NET migration has a mix of skills and roles. The developers who will be working in the code itself require three main skill sets:
Target platform experience. It is ideal that the developers have good knowledge and experience in the .NET Platform (either VB.NET or C#). This is the single most important factor for the VB6 to .NET migration.
Source platform experience. It is important to have resources on the team that are knowledgeable about VB6. This, is not required for all developers.
Application knowledge. Many questions will arise during the migration, and having someone with in-depth knowledge of the source code on the team will avoid wasting time figuring out what a block of code was trying to achieve.
The two most common ways of implementing a VB6 to .NET migration are either “Top-Down” or “Bottom-Up”. The “Top-Down” order is to start with the VB6 projects that are desired and working down to the migration issues. This is recommended if there is a need to do partial deployments, if the costs of additional testing and integration work is acceptable, or if developers are working on a proof of concept. “Bottom-Up” starts by fixing the upgrade issues in the generated code and then moving upward until the projects are fully functional. This requires that all the migration and compilation issues are solved before the application can be tested. Resource allocation is dependent upon the order chosen. Top-Down allocations are possible per project if the original developer of the VB6 project will be working on the migration. Due to the developer’s familiarity with the code, it will be easier to fix the different migration issues present in it. A more scalable approach is to allocate developers per VB6 file, with different files assigned to different developers. Each developer can fix the compilation and upgrade issues present in these files. This can significantly speed up the first stages of work. Another approach is to have a developer specialize in the solution of one particular type of migration issue. Fixing an issue usually requires some research at first, and further occurrences are fixed in a fraction of the time it first took. By using this approach, the developer’s efforts are optimized, and it also lends itself to having a large number of resources
tackling different migration issues in parallel, further speeding up the process.
6. Perform pre-migration tasks to improve quality Large systems usually require a modular transformation, implementation and re-architecturing strategies. It is not always straightforward to break up a legacy system into modules that make sense to transform, implement or re-architect on their own. Interdependencies within and between modules can be, and usually are, quite complex. To some extent, the old adage â€œgarbage in, garbage outâ€? applies to code migration. A VB to .NET migration requires certain activities to improve the quality of the code that will be generated during the automated migration. There are two types of pre-migration tasks that involve changes to the VB6 code base: Cleanup and Preparation. During Cleanup, maintenance tasks that are commonly postponed during the development cycle need to be performed. This might include removing code that is no longer used, removing redundant functions or methods, and some basic code and project restructuring. Computerassisted source code transformation tools typically look for, and tag, excessively redundant code in the first run. This redundancy is common when reuse was achieved through cut and paste. Excessively redundant code can be encapsulated and simplified. Preparation activities include modifying the applicationâ€™s code to improve the quality of the generated code. There are tools available to help identify code in an code in an application that will not convert cleanly. Some issues are easier to fix in VB6 than in .NET.
7. Manage risks Risk has to do with organizational disruption, past experience in meeting deadlines, available knowledge (related to new technology or packaged application), future dependence on a supplier, and other factors that can influence the final outcome of the project. Rather than an absolute measurement of risk, a ranking indicating the risk of each alternative in relation to the others must be arrived at. There are some simple things that can be done to mitigate risk in a VB6 to .NET migration project. First, convert a small, representative module (using Top-Down) before starting the whole migration. The performance of the migrated module can be tested and tuned. Analyzing the performance upfront will help identify potential issues and avoid surprises.
Second, closely track the effort required to migrate this first module. This will help with the validation of the estimate for the remainder of the application. Another risk mitigation tip: migrate to Functional Equivalence first before making changes to modernize or leverage the full functionality of the new platform. Several VB to .NET migration solutions will release developers from one legacy environment only to lock the organization into a proprietary runtime. Over time, this approach leads to additional costs, especially if royalties are associated with the proprietary software. Being tied to redistribution royalties can impact potential business models that an organization may want to explore in the future.
8. Quality Assurance Migration projects are more QA-intensive than other types of software development efforts. In general, 35-50% of the total effort will be consumed by testing activities. The QA team should make sure that test cases execute correctly in the VB6 application before running them on the migrated version.
9. Migration: functionality first The goal of any application upgrade is to first achieve 100% Functional Equivalence to the original VB6 application in the new platform before performing incremental changes to leverage the new functionality available in the .NET Framework. Throughout the project, project managers should have formal progress meetings, bringing in technical team members as appropriate. It should be expected that each vendor PM will provide regular status reports for each meeting. Within the team, someone should be appointed to take meeting minutes, documenting decisions made, actions required, problems and the plan to solve them, etc. After each deliverable, it is all important to monitor any issues that arise from acceptance testing and ensure they are resolved in a timely manner. Code that is not automatically migrated must be documented and marked for revision by trained specialists. This is when software engineering discipline must be exercised, test suites executed, transformation rules changed and manual changes made in an iterative loop until 100% Functional Equivalence is reached. The principle of Functional Equivalence is a highly useful tenet. It guarantees that each action taken on the application logic doesnâ€™t change
its functionality and therefore assures a correct recovery of the program logic. Utilizing automated tools without this principle will most certainly imply long and painful debugging processes. The resulting software running in the new platform might still require reengineering, componentization, refactoring and possibly functionality replacement and/or enhancement. Powerful source code understanding tools can now be used on the transformed code to gain insight on how best to re-architect the code. Not only are the tools to work on the new platforms much more powerful, but also the new generation of engineers is much more conversant with them. A corollary to platform migration and unification (all the organization’s systems can end up in the same platform) is that the application integration problem, disappear. When all organization’s systems run on the same modern platform, Service Oriented Architecture is readily implemented and the integration between modules and/or systems becomes simpler and transparent.
10. Validate via testing It is necessary to put together comprehensive unit and system test suites, for the whole system as well as for individual migration modules (if required). Test suites must be exercised by automatic tools that compare expected with actual results. Having a set of test cases will help the project to have very clear goals: to have the migrated application run the same test cases as the original system, and produce the exact same results.
11. Evaluate, learn, adjust The project scope and plan for a VB to .NET migration contains a definition of success criteria -- measurable and demonstrable outcomes to establish when the project is completed. This sets realistic expectations with stakeholders in the project, and in turn will translate into a more manageable and controllable project. The performance against these criteria should be carefully evaluated. Typically, this is done in a “post mortem” where “what went well” and “what did not go well” are discussed and documented in order to learn from the experience. While the primary outcome of a successful project is usually economic (tangible return on the investment), success if not always defined in financial terms. Other targets may be equally important: improved performance, ease of use (e.g. through a new graphical interface), improved data access, streamlined business processes, reduced errors, better support for sales or customer service, etc.
Modernization of legacy applications can positively impact revenues and costs – allowing an organization to extract additional economic return from existing investments while meeting the new requirements being placed on the IT systems. Project Phase
Requirements Definition: Roadmap; High Level Architecture; Scope, Budget
Establish Project Team & Set-Up; Evaluation of third-party tools and services
Architecture; Database; Prototypes; Test Plans
Product Installation & Configuration; Tool Set-Up; Construction Procedures
Language Conversion; System Services; Database Build; DCL; Interfaces
Enhancements; Integration; New Functionality
Unit; System Testing; User Acceptance
Documentation & Implementation
About Transoft Transoft, a leading provider of innovative and pioneering modernization solutions, helps clients maximize the potential of existing applications by safely moving these core applications to modern, open platforms while improving their functionality in the process. Transoft is part of IRIS, which has an exceptional reputation for delivering award winning, market leading solutions to more than 60,000 organizations worldwide. The technology and services from Transoft deliver rapid return on investment, reduced costs, improved productivity, and the ability to manage operational risk. Major organizations such as The Gap, L’Oreal, Boeing, Balfour Beatty and Christie’s, and thousands of other customers enjoy the business benefits of a Transoft application modernization strategy. We work with a large network of VARs, System Integrators, ISVs and technical partners.