Best Strategy or tools for migrating from VB6 to .NET/.NET Core [closed]

Question

My company has tons of legacy applications that are written in VB6.

We are in transitions from moving VB6 applications to .NET (3.5 specifically).

What would be the best strategy for moving form VB6 to .NET?

NOTE: Below update should go to "Project Management" and has nothing to do with the main question.

[UPDATE]: Thank you for your feedback so far
Now there are more question that pop up are

1. how would you assign developers to develop new applications?
2. Should there be a special one-time upgrade division that will convert legacy apps to new ones? Or should every developer participate on conversion process?
3. Should only senior developers participate on conversion? Junior developers? or mixed?

It seems like, the more I think about this problem, more questions just show up.

Answer 1

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.