William has been heavily involved in helping UK companies migrate their VB6 applications to .NET. William kindly agreed to a short interview. Enjoy.

William, could you just say a few words about your role inside Logica?

Hi Eric, I’m the Lead Architect for Logica’s finance business in the UK. The role is an interesting (and challenging) mix of client engagement – alongside strategy, proposition and organisational development.

Can you give us an example of the sort of scenarios you come across wrt to VB6 migration?

We see a real mix, ranging from business critical applications – front and centre on dealing desks, through to suites of dusty old utilities that hardly every change. The ease of use of VB6 was a double edged sword, particularly as institutions move to the .net platform – many have a large portfolio, with a very broad range of quality.

A typical scenario would include a suite of apps with code written in a range of VB versions, including those prior to VB6. The original version of VB is quite important in this context – apps developed in earlier manifestations can become more challenging to move across because the conversion tools target the “proper” VB6 ways of working.

Generally there’re quite a few OCX’s too and we see a number different databases (it’s not all SQL Server). Something else we’re very used to seeing is a complete lack of documentation and regression tests (maybe I should say “not seeing” :o).

These applications are becoming a real risk and some are increasingly costly to maintain.  Regulators are uncomfortable about unsupported critical applications. Migrating into the .net platform, either to vb.net or C# contains the issue. Clients are keen to move to new technologies in the simplest and most cost effective way so that their teams can quickly focus on developments in newer technologies and build teams with up to date skills.

How can Logica help in these situations?

We can get involved in a number of ways, helping with an initial portfolio assessment and the decision-making process around which applications to migrate, retire etc. This is generally an assessment of cost, risk and business criticality enabling a clear strategy to be built.

Once the target set of applications are identified we bring a standard set of tools and techniques to assess an application and work out the costs of moving into the .net platform. Logica has built a pretty strong partnership with Artinsoft now, the people who built the Visual Studio VB migration wizard – though we use an extended version of their tooling; this is more productive and makes our life easier than the standard downloadable version.

We generally do migrations as fixed packages of development and testing – and where needed we can also package the apps for deployment. With sufficient volumes we can take this work through to remote delivery locations to keep the costs under control.

Some people want a measured approach at low volume as a background task; others need to go faster – particularly where an app is part of a business critical suite. Much of this depends on the degree of change around the application – it’s more difficult to migrate a moving target.

Is this something you see happening increasingly more often?

We’re definitely seeing more interest in sorting this out over the last 6-12 months.

There’re a number of triggers to the engagements we get involved with – a need to integrate within the wider enterprise, support costs going up, the difficulties in keep developers engaged on older technologies. But more often, an increasingly demanding business with accelerating rates of change. These can all drive a migration strategy

And now of course, there’s the fact that the VB6 development toolset is no longer supported. As well as it being good practice to use tools that are maintained, compliance regimes in Financial Services can often dictate it an unacceptable operational risk to run critical applications on unsupported software.

What would be your advice for a customer with a significant investment in VB6?

Understand what you’ve got to start with. You don’t use the same approach for the whole portfolio; particularly you need to understand the needs from the business point of view. For example, do you really know what processes are being supported, how many users depend on them and how often? Some things you may be better leaving to slowly wither away, others need immediate and urgent attention.

Another key point to consider is that applications written in earlier versions of VB may need a fair bit of refactoring before you run them through the automated tools. You need to understand the assumptions being made by the tool to minimise the amount of manual, post-conversion work. The appropriateness of what goes into the tools makes a huge difference to the reliability of estimates and overall cost.

There’s a lot at a detailed level we could talk about – but testing is the other big one that people don’t usually spend enough time on. We get test analysts involved very early, during initial assessment. The lack of regression testing around earlier VB applications seems rather systemic, and requirements built up over more than 10 years will inevitably be patchy.

And finally, I gather you have been working with Logica to build an offering to help similar companies. What does that involve?

Don’t want to do the big sell here, but we have done a fair bit of this work. The experience, toolsets and organisation is there and we have solid repeatable processes. It’s a learning curve that many don’t want, particularly since it’s not that useful once you’ve dealt with your local problem.

Doing these migrations isn’t rocket science. It can create a heap of work, a lot of it pretty mechanical – and you can distract your development team for quite a while doing things that your business hasn’t asked for. The real reason to talk to us is to contain the risk and keep your focus for the business and future strategy.

Thanks William – and best of luck.

You can contact William via me if you think Logica may be able to help your company.