Best Strategy or tools for migrating from VB6 to .NET/.NET Core
Clearly this is a major undertaking which will involve lots of work.
So my advice would be to treat it like a very long term project.
Have a clear goal in mind, which addresses major issues like security, resilience, maintainability and the future of your applications.
Once this has been agreed on by the stake holders, develop a prototype system to test your assumptions with, where you can try out C# vs VB.net or MVC vs Webforms. I would assign your best developers for this.
Then start with one your small legacy systems, and build the core components which you will re-use in other areas.
At this stage, start with your more senior developers, but everyone must get involved and be familiar with the new framework.
This will ensure everyone is trained at the same time, and no one is left behind.
Depending on how many applications you have I would rotate developers, so all systems can benefit.
Also all new work must be done in your .net language not in VB6.
Gradually convert each one of your legacy applications. (I would only convert them if they are changing or if there is a clear benefit to updating them.)
This should give you a solid framework to use going forward, while still ensuring users functionality isn't hindered by your migration.
For example:
I've worked at a company which had roughly 40 or so VB applications.
Over time we have migrated all of these to C# and now (5 years later), we have roughly 150 c# applications (all in .net 2.).
These all share a common framework, making them easy to maintain, and extend where necessary.
Try replacing core functionality with COM enabled .NET libraries. "Hollow out" your existing VB6 apps by moving functionality to .NET bit by bit.
Beware of complete rewrites. Though they are tempting "because it is a clean cut" - usually madness lays ahead! Read "Working Effectively with Legacy Code" by Michael Feathers as a preparation. Though the book does not specifically go into "moving from one language to another" it does show a lot of real world pitfalls you will encounter.
I do think that all developer should have defined time slots where they do migration work on the legacy apps they developed before. Since they already have domain knowledge and know the problem space they should be the most productive.
Here is an adaptation of my answer to a similar question.
Converting large programs automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece of software, 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 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
This excellent Microsoft page recommends two third party migration tools as better than the underpowered built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. Artinsoft wrote the built in VB.NET upgrade wizard, this is their improved version. And CodeArchitects was founded by Francesco Balena, who wrote some of the classic books on VB6 and VB.NET.
The same Microsoft page also says:
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.
EDIT: Sung says in the comments: "I am not a big fan of auto generation of code because it is harder to debug initially and might take just as long as it takes to rewrite whole thing". I have to disagree strongly. In general I too am no fan of code generation, but in this case the resulting code will be structured identically to your original VB6 and should be almost totally functional. I haven't actually tried these tools myself yet, but from their customer testimonials this promise is fulfilled.
And I repeat the Microsoft advice just above, based on their experience of assisting many migrations - "a complete rewrite is far more costly and difficult than converting [my emphasis]" - a flat contradiction of the supposition that it might take the same time. If you want to improve the structure of the VB6, migration then gradual refactoring is likely to be far more cost effective than a rewrite.