20 questions your Code Conversion partner better have a good answer for: If they don't, you need to find another partner

23. July 2010 13:16 by Fzoufaly in General  //  Tags: , , ,   //   Comments (0)

I recently found this interesting list of questions on the Datatek Inc. website. I enjoyed answering them and I want to share ArtinSoft’s answers.

Go ahead and judge for yourself if ArtinSoft is the right partner for your VB6 migration projects.

Q1: If you are manually converting the code, how many different programmers will be converting the code and how are you ensuring consistency and accuracy?

A1: ArtinSoft does not execute manual migration projects. However, there is always a percentage of code that requires manual adjustments. All the team members in a migration project follow the same coding standards to ensure a high level of consistency in the manual changes. If a certain issue is detected multiple times in the source code, its fixing will be implemented in the automatic migration process.

Q2: If this is a manual conversion, how do you minimize the issue of bugs being introduced by each and every programmer, which will have to be found individually during testing?

A2: Most of the work is performed by an automatic migration tool. People working in a migration project share a Knowledge Base where they record every manual change they perform. This knowledge sharing process minimizes the number of bugs introduced by programmers.

Q3: If you are automatically converting the code, what percentage is automated and what percentage is manual?

A3: The percentage of automatic code migration changes depending on the source/target platform. For example, in the case of Visual Basic 6 to .NET automation reaches 95% of the actual lines of code. This level of automation ensures consistency in the quality of the generated code.

Q4: Our programmers still need to make modifications to our code in order to support ongoing business requirements. Is there a “code freeze” and how long is it?

A4: ArtinSoft understands that software applications are ever evolving creatures. We have developed a mechanism where it is easy to incorporate changes during a migration process, we call it continuous migration. This process minimizes the code freeze period to the last acceptance testing phase of a project.

Q5: When we receive the converted code back from you, are we required to make any changes in order for it to be functional?

A5: When ArtinSoft bids on a functional equivalence migration project, the code that is delivered is ready for deployment.

Q6: Is the converted code guaranteed to compile?

A6: In a functional equivalence project, the code not only compiles, it runs!

Q7: Once the code compiles, do you just hand responsibility over to us or are you responsible for problems found during testing?

A7: NO! (See answer 6!)

Q8: What are we, the customer, specifically responsible for during the conversion project?

A8: The customer is mainly responsible for the testing of the project. This responsibility starts with the creation and delivery of test cases to ArtinSoft and ends with final project acceptance. The testing workflow is the main path of communication between the teams. This process ensures that project expectations are clearly set up front and is key to the success rate of the project.

Q9: Can our coding standards be applied to the converted code?

A9: Our migration tool can be customized to include the application of your coding standards. Coding standards are identified and agreed upon during the initial phase of the project.

Q10: What kinds of customizations can we make to the converted code?

A10: ArtinSoft delivers code that is completely standard to the target platform. There are no dependencies on ArtinSoft or any strange “programming behavior”. Any programmer that is fluent in the target platform is able to understand and evolve the generated code. This ensures that your application really gets a new life under the new platform.

Q11: How maintainable is the converted code? How long have other customers stayed on code you have converted for them?

A11: The generated code is fully maintainable. Our customers continue to use and modify it long after it has been converted.

Q12: What happens if we don’t like how certain pieces of the code got converted?

A12: This can be approached at to different moments: before the migration stats or during the evolution phase of the application. Before the migration start, the conversion tool or the migration process can be customized to change its behavior according to your coding preferences. During the evolution phase, since the application is written in standard maintainable source code, it can be evolved using your normal software development process.

Q13: What happens if our code inadvertently makes use of undocumented features? Will you support that functionality?

A13: Yes! ArtinSoft guarantees functional equivalence. If it worked before, it should work after the conversion.

Q14: What happens if we have existing bugs in our code that run fine on our current platform (such as uninitialized variables). Are you responsible for making sure that everything works like it did on the old platform?

A14: Yes! ArtinSoft guarantees functional equivalence.

Q15: Can we get a fixed price contract for the conversion?

A15: Absolutely. The great majority of ArtinSoft projects are executed on a fixed price & fixed time basis. Our Ready™ assessment methodology together with our experience allows us to minimize the risk for our clients.

Q16: Are there any runtime charges for any support code and/or libraries you supply? Do we have ownership rights to this code?

A16: An important element in our philosophy is to minimize the amount of necessary support code. Code should be converted to its “native” counterpart as much as possible. In case a support class is needed, the client will have full access to the source code and absolute independence from ArtinSoft moving forward.

Q17: How are we charged if we miss giving you a file after you have already started the conversion?

A18: ArtinSoft always include a price per line of code that can be used for adding/subtracting code from a migration project during its execution. Clients will always know beforehand how much additional work is going to cost.

Q18: How long does the conversion take?

A18: Each project is different. Typically, project length is a function of the size of the source code. ArtinSoft always insists on performing an assessment before the start of the project that will clearly state the required effort to successfully complete the migration.

Q19: What type of guarantees do you provide?

A19: ArtinSoft guarantees functional equivalence between the source and converted code. We typically include a guarantee period when clients can report bugs after project acceptance and ArtinSoft is responsible to fix them.

Q20: How long have you been doing code conversions?

A20: ArtinSoft has been doing automated code conversions since 1993 (we’re about to reach legal age!). In fact, ArtinSoft was founded on the premise that source code should be freed from its platform dependencies. Since day one, we’ve been applying our Artificial Intelligence research to providing cost-effective and low risk solution to code migrations. Companies choose ArtinSoft for our proven experience and comprehensive methodology.

VB6 migrations to a new level

12. April 2010 08:17 by Fzoufaly in General  //  Tags: , , , ,   //   Comments (0)

I am proud to announce that today ArtinSoft released version 4.0 Beta of its flagship product the Visual Basic Upgrade Companion.

This new release once more collects our learnings from migrating millions and millions of lines of code from Visual Basic 6 to VB.NET and C#. 

This release revolves around a number of themes:

1) Visual Studio 2010 compatibility: You can now use the VBUC to create projects that are compatible with Visual Studio 2010.

2) Take advantage of new framework features: The code generated by the VBUC now takes advange of some advanced features of the .NET Framework to improve the quality of the code avoiding dependencies to any third party runtime.

3) Compatibility with Windows 7 and 64 bits system: The platform is evolving and the VBUC is evolving along with it.  Now the VBUC is compatible with Win XP, Vista and 7 on both 32 and 64 bits systems.

4) Impoved usability: We are trying to minimize the learning curve to start a VB migration project. There will be even more changes in this theme for the next release. (I am specially excited about this!) 

Please read our official press release, learn the specifics of version 4.0 or give it a try!

You can also watch a video demo on the Microsoft site channel 9: http://channel9.msdn.com/posts/VSIPMarketing/VSIP-Partners-CAN-DO--ArtinSoft-Visual-Basic-Upgrade-Companion/ 

Aberdeen Group recognizes ArtinSoft as a key player in the VB 6 migration industry

Aberdeen Group recently published a report titled “Migrating from VB6 to .NET: The challenge of Software Agility in a Volatile Economy”.

The report contains a good summary of the status quo with respect to Visual Basic 6 renewal efforts.  It is based on a survey of 130 organizations at the end of 2008. 

The Aberdeen report contains lots of advice for organizations that are faced with the challenge of upgrading their infrastructure, I think it is worth reading it.

ArtinSoft is very proud to have been recognized as a key player in the Visual Basic migration game along with a number of its outsourcing partners.  This shows once more how our 15 years trajectory in the migration business is our best letter of presentation.

In his summary of the report, Aberdeen analyst Michael Lock also shows how best in class companies have a much greater tendency to use automatic migration tools to support their porting efforts.  During these times of financial uncertainty is more important than ever to minimize the cost of evolving your infrastructure and automation is certainly a good way of doing so.  ArtinSoft approach to automatic migration is aimed at minimizing the cost of reaching functional equivalence while at the same time ensuring that all delivered code is completely .NET native and ready to be evolved to the next level by our customers.  ArtinSoft offers the best balance between cost speed and future insurance.  Jose Aguilar also analyzes some of the conclusions from Aberdeen in this blog post.

If you are deciding what’s your next move with VB6, you should certainly read the Aberdeen report and you should look at our Visual Basic Upgrade Companion 3.0 and our new technical resources site www.VBtoNET.com .

Visual Basic migratioon now faster than ever!

6. May 2009 09:44 by Fzoufaly in General  //  Tags: , , , ,   //   Comments (0)

Today ArtinSoft launched the Visual Basic Upgrade Companion 3.0 both for our Enterprise and Developer Editions.  This latest release of the best (I am biased!) Visual Basic migration tool in the world is focused on reducing the total effort of a migration project.  Together with the conversion tool release we also revamped its companion technical site http://www.vbtonet.com/ .  This site, which will be continuously updated in the following weeks, is the perfect side help to any person that needs to complete a migration project.  It contains everything from a getting started guide to how-to articles with advanced migration topics.

At ArtinSoft we are truly proud of this release and we continue to be fully committed to support our customers in their transition from VB 6 to Visual Basic .NET or C#. 

Specifically, here are the latest additions to the VBUC 3.0.  Click here to get a trial of this exciting product.

VBUC 3.0 New Features

 Source Code Conversion Features
  • Windows API and 'Declare' Support
    VBUC 3.0 introduces support for external DLL function declarations and invocations. A vast research was performed to identify the correct way of declaring and passing parameters and return types for primitives, classes, enums, structs, fixed lenght strings, arrays and combinations of these types.
  • Increased Support for Windows Common Controls Conversion
    VBUC 3.0 introduces a substantial amount of improvements for the conversion of Windows Common Controls to native .NET controls.  An extensive effort was performed to identify and resolve issues related to these components which are present in most VB6 applications. The main improvements are related (but not limited) to the following controls:  ImageList, ListView, StatusBar, Toolbar, TreeView.
  • Public Class Instantiation Models Support
    Public classes in ActiveX EXE/DLL projects may have different instantiation models (multiuse, singleuse, etc.) To achieve the same behavior in .NET a whole conversion solution was implemented and incorporated into VBUC 3.0.
  • Default Property Resolution Through Helper
    The VBUC contains a new helper class designed to resolve several late binding issues that are not solved by the typing mechanism. This solution significantly reduces compile errors and EWIs while providing higher functional equivalence.
    This solution resolves the EWIs related to late-binding and default property issues which represent around 50% of known issues from older versions.
  • Data Access Conversion Improvements
    The data access conversion to ADO.NET with System.Data.Common has been a very popular feature from the previous VBUC versions.  VBUC 3.0 introduces several improvements to this feature. It includes enhancements to the helper classes functionality as well as additional members coverage (clone, sort, getrows and many others)
  • IsMissing Support
    VBUC 3.0 introduces support for the IsMissing function. Since VS.NET doesn't include the concept of missing parameters, VBUC now generates a code pattern that produces the same behavior by taking advantage of nullable types and overloading.
  • NotUpgradedHelper for Not-Upgraded Statements and Members Handling
    A very common problem with older versions of VBUC was the handling of NotUpgraded members and statements.  They were usually generating compile or runtime errors that made the post-VBUC manual work more difficult.
    VBUC 3.0 introduces a helper class to report and handle the usages of not supported elements while avoiding compile and runtime errors.
  • Multiple improvements to existing features
    Around 450 individual improvements were implemented for VBUC 3.0.  Most of them are related to providing increased automation and enhance the resulting code quality, others are related to other areas such as robustness and graphical interface.
 Performance Improvements
  • Speed Boosting
    For VBUC 3.0 several time performance improvements were implemented to achieve a substantial improvement, reducing to 50% the required time to perform an upgrade process.  Additional time improvements could be experienced when converting large projects which used large amounts of memory.
  • Reduced Memory Requirements
    Memory usage was also significantly improved.  Based on tests over medium projects we estimate around a 30% improvement.  It is estimated that more significant improvements will be experienced with bigger projects.
  • Assessment Tool Integration
    The VBUC Assessment Tool functionality has been incorporated into the VBUC. Users can now execute the assessment process from the VBUC main window. One important advantage of this approach is that users can solve migration warnings before executing the assessment process, allowing the obtention of better quality information.
  • Additional Assessment Reports
    Two additional reports have been included into the integrated assessment process:
    • An advanced dependency analysis that shows internal-dependency trees per project.
    • A shared and potential-duplicate files report.  It includes the following sub reports:
      • A shared files report indicating which projects include each shared file.
      • A potential-duplicate files report indicating which projects include each presumed duplicate file.
      • A projects list sorted topologically with LOC counts for each project where shared and potential-duplicate files are counted only in the first project they occur.
 Other Features
  • Graphical Interface Status Information
    The VBUC 3.0 graphical user interface shows detailed information for each project.  It shows sizes, progress and status by project and by source file detail.
    It helps the user to understand the volume of work required for each project and its current upgrade progress as well as to identify any eventual pieces of code that may have not been fully converted.
  • EWIs and Upgrade Report Improvements
    Several modification have been implemented to the upgrade messages generated by VBUC into the generated code.
    • UpgradeReport Synchronization: for previous versions of VBUC the UpgradeReport didn't show properly all the EWIs generated into the upgraded code.  For VBUC 3.0 this report includes all the EWIs generated in the converted code plus the global EWIs that are not included into the target source code.
      In addition, the accumulated counts per section where also improved to show the correct amount of occurrences.
    • Links to Online Documentation: Hiperlinks are added for each EWI to its corresponding online documentation in the new www.vbtonet.com site.
    • Restructuring: The EWI message structure was modified to show the numeric code first.  Also some messages where improved and some EWIs were removed or merged.
  • Increased Robustness and Logging
    Several actions were taken to handle and recover from unexpected situations.  In the event that any exceptional situation may arise, an window is displayed explaining the issue and providing the user with options to generate debugging information that can be sent to ArtinSoft support for diagnosis and recommendations.
 Products, Versions and License Types Formalization
  • Developer and Enterprise Editions
    The second version of VBUC Developer Edition is released with VBUC 3.0.  The development process has been formalized to syncronize the maintenance and releases of both versions.  The Developer Edition includes an improved activation and licensing model as well as an easier on-line sale mechanism.
  • Trial Licenses
    Both Developer and Enterprise editions support trial licenses.  Developer trials are now available for download in the Artinsoft web site.
  • ASP Upgrade Engine Integration
    The ASP Upgrade Engine has been integrated into the VBUC 3.0.  It is now installed together with VBUC.  The license file can still restrict the use of ASP upgrade abilities though.
  kick it on DotNetKicks.com

Learn about low-cost and low-risk migration options with Avanade and ArtinSoft

18. March 2009 04:48 by Fzoufaly in General  //  Tags: , , , , ,   //   Comments (0)

On Wednesday April 15th 2009 Avanade and ArtinSoft will host a webinar on how to quickly and cost effectively renew your Visual Basic 6 applications.

Here’s an excerpt from the invitation:

“Don’t miss this chance to learn more about VBUC and other cost effective migration options, including:
• Which migration strategy works best for you (complete, partial,
  coexistent, partial development)
• How to reduce project risk, costs, and time to market
• How to guarantee business continuity by preserving knowledge
  invested in legacy applications“

You can RSVP and make sure you don’t forget to attend.

Large Companies, Successful VB6 Migrations

11. March 2009 11:51 by Fzoufaly in General  //  Tags: , , , , ,   //   Comments (0)

Here is a summary of some recent case studies that we have produced with our customers. 

The message is common: Visual Basic 6 to C# migrations are an excellent alternative that saves time and money when you need to move your application to .NET.


This Texas-based company provides geo-navigation solutions for the horizontal drilling industry, and when the end of official support for the VB6 development environment was announced, they turned to ArtinSoft to migrate their LatNav application from VB6 to C# on a turn-key basis, using a slightly customized version of the Visual Basic Upgrade Companion.

“Utilizing the Visual Basic Upgrade Companion saved us about one year of development and $160,000. This conversion will allow us to leapfrog well in front of our competition” -- Ken Bowdon - HSI founder

Read the full HSI case study.


After discarding a manual rewrite and the Upgrade Wizard, MDA –a software services provider for the real estate sector– settled for ArtinSoft’s Visual Basic Upgrade Companion tool, with which RDO was transformed to ADO.NET, third party controls were converted to native .NET controls, Component One’s True DB grid was upgraded to the latest version of that component, and coding standards that were common place when developing in Visual Basic 6.0 were also migrated to equivalents in VB.NET.

“We looked at different options, like a rewrite and the Upgrade Wizard. The UW couldn’t cater for our needs, especially since we were going from RDO to ADO.NET. A rewrite would have been about a five-year project for us, and possibly in the region of US$500,000. Using the Visual Basic Upgrade Companion represented an estimated saving for the project of about 3 years and US$300,000”. -- Rodger Beadle – Technical Director, MDA

Read the full MDA case study.


Vertex, a leading global BPO and customer management outsourcing company, managed to ensure compliance and business continuity by upgrading not one, but two mission-critical applications from VB to .NET using a customized version of the Visual Basic Upgrade Companion (VBUC). These case studies underscore the joint efforts made by both companies, which proved to be decisive to accomplish the goal of having both migrated applications up and running within some serious time constrains.

"ArtinSoft has been an excellent company to work with. They have been responsive to requests from Vertex to change their processes in order to accommodate the way in which we work. They have provided us with daily updates throughout the migration life cycle and have worked in partnership with Vertex to resolve any issues that have arisen in a pragmatic and expedient manner." -- Sue Craig - Senior Project Manager, Vertex

Read the full Vertex Omiga Case Study.

Read the full Vertex Supervisor Case Study.

Banamex / Citigroup

Learn how Banamex, one of the most widely recognized financial institutions in Latin America and purchased by Citigroup in 2001, was able to migrate over 5 million lines of code from VB6 and ASP to C# and ASP.NET using ArtinSoft’s Visual Basic Upgrade Companion, in compliance with Citigroup’s corporate policies for quality assurance and information security. The project also included the creation of an effective collaboration environment and the implementation of highly advanced security tactics in order to guarantee full confidentiality in data handling.

Read the full Banamex/Citigroup Case Study.

I've decided to move away from VB6. Now What?

At some point in time companies decide they want to leave a certain platform.  Let’s not focus on the reasons why they decide to move but on HOW to move instead. Companies reach the decision to move on their own timetable.

Once you have decided that you want to move away from VB6 then ArtinSoft comes into play.  The purpose of my blog is to show that there is a way out that is good, fast and cost-effective.  Compared to what? You might ask, let’s see.

Once you decide to move (let me be clear, you made the decision to move, then the rest of the discussion applies) you have to assess your applications and make a decision on HOW to move them one by one. 

There are three axes along which we recommend our customers to make the analysis:

  • How unique is the functionality to your business? For example, if you have a general ledger that does not have any particular features for your business, if you have a “me too” app that does not give you an advantage over your competitors, well, you should consider just buying a package and replace it.
  • How good is the technical quality of your source code? Have you followed best practices in VB?  Is your code maintainable by a third party? (Can they understand it?) If the answer is no then migrating it to a new language is not going to improve this situation.  Consider a rewrite.
  • How fast is the functionality changing to meet business goals? Is the business process it supports fixed?  Do you anticipate that very minimal changes will happen before retirement?  Then you should just leave it as is (one caveat here, in some industries because of regulatory issues you might still make sure you are on a fully supported platform even if the application does not change).

Now, if you have an application that provides you a business advantage, that is of good technical quality and that needs to adapt to new business challenges, then you have a good candidate for a migration.

For applications with the above characteristics, why is a migration better than a rewrite?

  • Cost: when we look at cost there are several dimensions.
    • Cost of the actual migration process: An automatic migration to functional equivalence can be done with about 20% of the cost of a rewrite.  Most of that cost is testing and fine tuning of the application to the new platform.
    • Training of end users: Since the application is functionally equivalent it is not necessary to retrain end-users.  With a rewrite, chances are that the output is not going to be functionally equivalent unless you follow an algorithmic approach just like an automatic migration and therefore end users need a retraining.  In addition to the actual retraining cost (which can be enormous – e.g. we worked with a customer whose system required a 6 weeks training time, for 3000 users.  An application replacement or rewrite would have started with that hole in front of them) but the opportunity cost.  New software, new mistakes, how does that impact the business continuity?
  • Time: An automatic migration process can also be done in about 20% of a rewrite.  This means that you can free up resources much faster to actually build new functionality that the business requires instead of attempting to replicate functionality that already works.
  • Quality: An automatic migration does not fundamentally change the architecture of the original application (even if certain aspects like data access and some pieces of GUI architecture do change). The question is: do you really need to change the architecture for the whole application? Probably not. You might need to change the architecture for certain processes.  The code that is generated by ArtinSoft is completely ready for evolution.  No strange variable names, all comments preservation, no restructuring of the code, etc.  Even if in the worst case scenario you need to rewrite a certain piece of the application it is always a fraction of the total cost.


How to move billions of lines of code from VB6

Danish magazine Version2 published an interesting article last week on VB6 migrations: http://www.version2.dk/artikel/9908-saadan-flyttes-milliarder-af-kodelinjer-fra-vb6#forum_post_anchor .

Microsoft is finally waving goodbye to Visual Basic Version 6. Its successor, VB.Net, is not backward compatible, but the company Artinsoft from Costa Rica can help with a translation machine.

By Tania Andersen, Wednesday 11 February 2009

This article really shows momentum in northern Europe.



More than 800k lines of ISVs code successfully migrated using the ArtinSoft Visual Basic Companion

ArtinSoft recently published a number of case studies of Visual Basic migrations for ISVs.  The projects were successful both from the technical as well as the economical perspective.  If you are an ISV and you are considering an evolution of your application and a port to the .net platform I encourage you to take a look:http://www.artinsoft.com/vertex-omiga-vb-to-net-migration-case-study.aspx




 In this blog I am trying to be as unbiased as possible in reporting my opinion with regards to VB migrations.  This time I am mentioning the case studies as evidence that a lot of the conceptual discussions that I have are actually happening in reality.  It is interesting to see how many of the comments to this blog tend to be from skeptics and from people that just love VB6 and do not want to abandon it.  My purpose is to show that there is life after VB6 and that an automatic migration is not only possible but, in many cases, a great alternative for your evolution plans.Please let me know what you think of the case studies.


VB6 Runtime WILL be supported on Windows 7 but no plans to support it on future version of windows.

13. January 2009 14:53 by Fzoufaly in General  //  Tags: , , ,   //   Comments (0)
I spoke to Paul Yuknewicz who is a Program Manager on the Microsoft Visual Basic team and who is quite involved with everything related to VB6 and its migration process.  Paul said and I quote: "VB6 runtime will be shipping and supported as a part of Windows 7, however there are no plans to ship it in future versions of Windows."  Microsoft will surely release an official document stating this in the near future. What is my take on this latest Microsoft move in the VB6 saga?  Well, I guess Microsoft had to react to the fact that VB6 is still widely popular and that a lot of businesses have delayed (procrastinated??) the decision to move to .NET.  From that perspective I believe this is the right move for Microsoft.  They want to minimize the impact of the end of life for Visual Basic 6.On the other hand, I have to wonder, why do people seem to not want to upgrade?  Over the years I have formulated a number of hypotheses as explained below. 
  • Migration is perceived as expensive: In the short term is certainly cheaper to do nothing than to migrate, however, if you have a valuable asset you want to make sure you can extend its life (and therefore ROI) as much as possible.  Automatic migration is the best alternative to achieve it.
  • Migration is perceived as lacking value: I have often heard how by automatically migrating an application at the end I get the same application and therefore I did not gain anything.  This is also false.  Once you upgraded the source code you have injected new life into it.  Your application has suddenly extended its life expectancy and (again) its ROI.  Maintenance and evolution of a .NET application is safer than of a VB6 app.
  • VB6 Applications are not evolving: Can this be true?  It is possible that companies have VB6 applications that support a business function that is not evolving.  If this is the case, leaving applications in VB6 is just fine and the fact that now Microsoft supports VB6 in Windows 7 gives a new breath to those applications.  However, in my more than 15 years of experience in the IT industry I have yet to see an application that never changes!  It is important to remember that the Visual Basic 6 Development environment is off main stream support by Microsoft. 
  • Applications will be retired before VB6 stops working: This is a plausible for a number of applications.  Companies sometimes choose a substitution strategy and just retire applications, or business processes stop being important and therefore the applications that support them are no longer necessary.  These cases certainly happen, and a number of applications might be in this category but it cannot be the great majority of them!  Additionally, companies sometimes believe that substituting an application for an equivalent one is cheaper than migrating them.  Well, I dare them to review this assumption make sure they run a complete comparison.  
  • It’s just procrastination: The famous “if it ain’t broken don’t fix it!” … do I have to comment on this??  May this be the reason why VB6 is still around?
  • There’s just too much VB6: This is the argument Gartner used to make for COBOL: it would be too expensive to migrate all the COBOL.  In fact, I have even heard this from an IBM executive who told me that at some point they were scared that all the mainframe code would migrate to Java (and therefore business rules would no longer be trapped in a mainframe) but then they run the math and just relaxed!  Of course, there is no real automatic solution for COBOL!!!!  For VB6 is a different story (ArtinSoft infomercial: http://www.artinsoft.com/pr_vbcompanion.aspx ).
 What is your position?  Am I missing a category of reasons why VB6 is still around?


Is the grass greener while doing green-field development?

Milan Negovan in his blog aspnetresources recently published an excerpt of Michael Feathers' book Working Effectively with Legacy Code.  I liked the excerpt so much and I believe that it is so pertinent to the topic of my blog that I also will reproduce it verbatim.


Often people who spend time working on legacy systems wish they could work on green-field systems. It’s fun to build systems from scratch, but frankly, green-field systems have their own set of problems. Over and over again, I’ve seen the following scenario play out:

An existing system becomes murky and hard to change over time. People in the organization get frustrated with how long it takes to make changes in it. They move their best people (and sometimes their trouble-makers!) onto a new team that is charged with the task of “creating the replacement system with a better architecture.”

In the beginning, everything is fine. They know what the problems were with the old architecture, and they spend some time coming up with a new design. In the meantime, the rest of the developers are working on the old system. The system is in service, so they receive requests for bug fixes and occasionally new features.

The business looks soberly at each new feature and decides whether it needs to be in the old system or whether the client can wait for the new system. In many cases, the client can’t wait, so the change goes in both. The green-field team has to do double-duty, trying to replace a system that is constantly changing.

As the months go by it becomes clearer that they are not going to be able to replace the old system, the system you’re maintaining. The pressure increases. They work days, nights, and week-ends. In many cases, the rest of the organization discovers that the work you are doing is critical and that you are tending the investment that everyone will have to reply on in the future.

The grass isn’t really much greener in the green-field development.


I concord 100% with Michael Feathers.  Rewriting code is something that can be achieved only at a very large rate of consumption of time and money!  My thesis is that migration, specially automatic migration, is often the best option.  You can easily change the platform and then focus on rewriting/rearchitecting only the pieces that truly deserve it.  This has been proven over and over again at ArtinSoft.

Aggiorno Beta2 is out!

5. June 2008 02:49 by Fzoufaly in General  //  Tags: ,   //   Comments (0)

How did ArtinSoft got into producing Aggiorno (www.aggiorno.com )?  Well after more than 15 years in the software migration market we learned a few things and we are convinced that developers want to increase their productivity and that automatic programming is a very good mean to do just that.

Aggiorno is the latest incarnation of ArtinSoft proven automatic source code manipulation techniques.  This time their are aimed at web developers.

Aggiorno, in its first release, offers a set of key automated improvements for web pages:

- Search engine indexing optimization
- User accessibility
- Error free, web standards compliance
- Cascading Style Sheet standard styling
- Site content and design separation

Aggiorno's unique value proposition is the encapsulation of source code improvements, utterly focused on web developer productivity in order to quickly and easily extend business reach.

At Microsoft TechEd in Orlando this tuesday June 3rd 2008 we announced the availability of Beta2 and we have included all the suggestion from our Beta1.

Download the Aggiorno Beta2 now and let us know what you think.


ASP.NET & Web Standards

9. May 2008 11:38 by Fzoufaly in General  //  Tags:   //   Comments (0)

Aggiorno is an add-in for Visual Studio 2005/2008 that can swallow horrible non-validating markup and help you make an ASP.NET site web standards compliant with little effort.  With Aggiorno web developers can improve their ASP.NET or HTML sites by making them comply with the latest web standards and incorporating the latest technology trends. This will immediately mean increased productivity and immediate business value.

Beta 1 has just been released, so you might want to give it a try and send some suggestions to the development team.


VB Runtime supported in next Windows

Here is an excerpt from an article that Greg DeMichillie wrote on Directions on Microsoft April Edition:

"The planned follow-on release to Windows Vista, code-named Windows 7, will not include the Visual Basic 6.0 (VB 6) runtime libraries, Microsoft has begun informing customers. This sets a timeframe for the final end of support for the runtime."

As we have informed on several occasion in this Blog, Microsoft is performing all the normal steps to retire a technology from market.  Visual Basic 6 was/is a tremendously popular technology but never the less it will have to go away.

Jarvis Coffin once said: "All technologies fade away, but they don’t die."  This is most probably what is going to happen to VB6 (hey.. we still have COBOL code written more than 30 years ago that is alive and kicking!!!) but the question I have for you is: will you embrace the new technology?  Or will you fade away with it?

It is time to upgrade your skills as a developer and also to migrate your application to greener grounds. 

ArtinSoft has been hugely successful at migrating customers as Eric Nelson (Microsoft UK DPE and blogger) recently mentioned: "Artinsoft have a lot of VB6 migration experience and can help you do the migration - either by licensing their VB Upgrade Companion or by taking advantage of their migration services. Artinsoft are doing some great work with some of my UK ISVs helping them move off VB6."

If you have any questions or comments regarding your migration strategy let's cover them in this blog.

UPDATE March 11th 2009: The title of this post was: "VB Runtime NOT in next Windows".  However,  Microsoft has recently updated the support policy for Visual Basic 6 Runtime.  The new policy states that the VB runtime is now supported for the full lifecycle of Windows 7. 

PS: You can read the inflammatory comments I got over the past week below!


April 8th 2008 and the end of Visual Basic 6 Support

8. April 2008 10:04 by Fzoufaly in General  //  Tags: , ,   //   Comments (0)

The date has arrived Visual Basic 6 leaves Extended support today.

Rob Helm recently wrote on "Directions on Microsoft": "Some organizations will let support lapse on the VB6 development environment, gambling that any serious problems in the VB6 environment has already been discovered"  Additionally, Rob adds: "... organizations remaining loyal to VB6 applications will have to make increasingly heroic efforts to keep those applications running as their IT environments change."

Organizations that GAMBLE with their business continuity, IT professionals that need to make HEROIC efforts to keep applications running!  Don't you believe that maintaining an IT organization supporting a business is already enough of an effort to add to the mix unsupported applications?

Do you plan to be a GAMBLING HERO or is it about time to consider ways out of Visual Basic 6?

Well this might be just the right time.  ArtinSoft is about to release a new version of the Visual Basic Upgrade companion. The effort required to migrate has been reduced even further and it now makes more sense than ever to automatically upgrade your applications to C# or VB.NET.

Have you been procrastinating the decision to move?  Act now!!

Aggiorno is coming out of stealth mode: www.aggiorno.com

14. January 2008 12:47 by Fzoufaly in General  //  Tags:   //   Comments (0)

Happy 2008!

During last year, ArtinSoft has also been working on a new product that we called Aggiorno ( www.aggiorno.com ).  Aggiorno is a Visual Studio add-in designed to increase the productivity of web developers.  Aggiorno helps developers with a broad range of topics like web standards, SEO (Search Engine Optimization), Accessibility, XHTML, ASP.NET, etc.

If you want to know more about aggiorno you can visit our new web site or the official blog: www.aggiorno.com\blog .

 In this blog, I will continue to discuss Visual Basic Upgrades and its implications.  By the way, customers are increasingly getting more excited about the speed and safety of migrations vs rewrites.


2008 is the final warning to move VB6 applications to .NET

27. September 2007 06:51 by Fzoufaly in General  //  Tags:   //   Comments (0)

Rob Helm, director of research at Directions on Microsoft, recently answered the question "Do the new releases of the Microsoft platform have an impact on the issue of upgrading applications from Visual Basic 6 to Visual Basic .NET?" with the quote that is the title of this post.

He said that the new platform updates really do not have an impact and that you should not wait any longer to move. He emphasized that after the end of support date for VB6 the support will only be through a special support contract with Microsoft that typically is "very onerous" and increasing every year.

Additionally, Rob Helm mentioned something that I had not noticed. Did you know the name of Visual Basic .NET is now officially only "Visual Basic"? Definetely another sign pointing at the future!

Microsoft improves compatibility libraries for VB 6.0: Visual Basic 2005 Power Packs 2.0

24. September 2007 07:06 by Fzoufaly in General  //  Tags:   //   Comments (0)

Microsoft recently started to distribute a new version of the Visual Basic 2005 Power Packs. 

Link to Download details: Microsoft Visual Basic 2005 Power Packs 2.0

Notably, the routines that are included help with the automatic Upgrade/Migration of VB6 to .NET.  From the MSDN web site:


" Overview

The new Line and Shape controls included in this version of the Visual Basic 2005 Power Packs are a set of three graphical controls that enable you to draw lines, ovals, and rectangles on forms and containers at design time making it much easier to enhance the look of your user interface. These new shape controls also provide events such as click and double-click allowing developers to respond and interact with end users.
The Printer Compatibility Library allows projects that used the Printer and Printers Collection in Visual Basic 6.0 to be upgraded without having to re-write your printing logic. By simply adding a reference to the library, declaring a Printer and making a few minor syntax changes, your project will be able to print using the Printers collection and Printer object as it did in Visual Basic 6.0. This version adds a new Write method to the Printer object which allows you to print text without a forced carriage return similar to the semicolon syntax used by Print method in Visual Basic 6.0.
The PrintForm component is designed to bring back the ability to easily print a Windows Form. With this the new PrintForm component you can once again layout the Windows Form exactly as you want it and allow your users to print the form as a quick report."


I'd like to relate this post with the one I did a few days ago related to performance (http://blogs.artinsoft.net/fzoufaly/archive/2007/0... ).  In the previous post I was arguing about the use of the VB6 Compat library from .NET applications.  Basically, I was arguing that the VB Compatibility library is written and distributed by Microsoft and therefore users should not be afraid to use it in their programs.  TThe same goes with the power pack Microsoft is now releasing.  The power pack contains a number of functions that are not directly addressed by the basic .NET framework but that are widely used and requested by VB programmers.  So what is the right solution?  Well, program them in .NET!!!  I mean, is there another way to provide functionality that is not by programming it?  Again, don't be afraid of using these routines more than you would be of any control you use in your app.  And also, do not worry about the performance hit!!

Will your VB6 application continue to work on Vista?

19. September 2007 05:19 by Fzoufaly in General  //  Tags:   //   Comments (0)

Microsoft is committed to support the vb6 runtime environment on Vista. However they will not continue to support the IDE: the development environment is not officially supported by Microsoft on Vista.

More detailed information can be found at: VBRUN and ftponline

Additionally, do not forget to also verify the support of your third party controls. Are they being supported by their manufacturer?

Many companies have already moved or are in the process to upgrade their Visual Basic Applications to .NET. However, many others are procrastinating their decision. Which type are you? Dont'you think it is time to move yet? What are you waiting for?

Performance of migrated VB6 applications to .NET

13. September 2007 10:34 by Fzoufaly in General  //  Tags:   //   Comments (0)

A common question when upgrading VB6 applications to .NET is regarding the performance of the application.

The short answer is that the migrated app typically performs as good as the original application. Let's dive into a couple of common issues that customers typically worry about:

1) the use of the VB6 compatibility classes in .NET: First of all, I believe this is a very bad namespace name! Everytime you hear compatibility library you think about performance. However, in this case, all the classes in the compatibility library are implemented in .NET. They are included just to simplify the maintainability of the code. The functionality that they provide is not directly provided by .NET, therefore, the correct way of implementing it is to just program it in .NET which is exactly what the compat classes do. NO performance penalty here! In addition, these classes are part of the .NET framework, thay are supported by Microsoft and they will continue to be supported for the forseable future! If there is a function in there that you want to use it, just do it!

2) COM Interop: The VB Upgrade Wizard generates primary assemblies for the COM component that are referenced from VB6. This is of course the fastest way to communicate with them from .NET. Now, typically, COM components are black boxes that presumably execute non trivial functionality. This means that typically the time spent by the execution of the COM component is orders of magnitude larger than the time spent in the calling of the component from .NET. Therefore the performance impact is negligible. This is not true of course if the COM interface is very chatty as you will have to go through the primary assembly overhead many times.

The reason to eliminate COM interop is normally not one of performance. You want to eliminate COM components for maintainability reasons, for deployment reasons or to take advantage of newer versions of the components. If you just want to maintain the same functionality COM interop does not present a performance situation.

In summary and reinforcing the introductory statement a converted application from Visual Basic 6 to .NET typically performs in the same way as the original one.

Have you had a different experience? Let me know!