This is a copy of my answer to the duplicate question (as CW) because I want to reply to the "always rewrite" answer that's currently top-voted here.
My advice is don't underestimate the effort of conversion - be very cautious about embarking on a rewrite. It's a common pitfall to start out optimistically, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.
...and here's a blog post by a Microsofty that somewhat agrees with me:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large .....
Hence I quickly became a fan of Migrate or Reuse as the right approach for most companies. Interestingly though, Rewrite is a less risky option than it once was. Many companies who still have significant VB6 projects also now have strong .NET skills gained on other projects, improved software development practices (including automated tests – a must IMHO for Rewrite) and have even taken the time to refactor elements of their VB6 codebase over the last 6 years. That said, I would still place Rewrite below Migrate or Reuse for most companies.
Quote from an excellent Microsoft webpage
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
Also the renowned VB expert Dan Appleman said:
In most cases porting [VB6 to VB.NET] is stupid and a
complete waste of money.
And Joel said a while back:
The single worst strategic mistake
that any software company can make [is
to] decide to rewrite the code from
scratch.
A couple of other useful links about migration including links to another free book from Microsoft.
One.
Two.
Three.
Microsoft page including screencast with their answer to "how to migrate"
