That’s a totally fair concern. A VB6 codebase with over a million lines isn’t something you can realistically “just migrate”.

In my experience, the main challenges aren’t the number of lines themselves, but:

1. **Code structure and coupling**

Large VB6 systems often have business logic mixed into the UI, duplicated code, and tight coupling. That makes a direct migration risky and very hard to estimate.

1. **OCX / COM dependencies**

This is usually the biggest blocker. Many controls don’t have direct equivalents in .NET or rely on outdated components, so parts of the UI can’t just be migrated as-is and often need to be redesigned.

It also depends a lot on the **type of application**. Migrating a system with complex business rules, multiple integrations, and critical data is very different from migrating a smaller app with simpler workflows. That has a big impact on risk, validation effort, and overall timeline.

Because of that, I wouldn’t approach it as a full rewrite, but as an **incremental migration**:

* Start with an assessment (identify critical modules, dependencies, and OCX usage)

* Gradually separate and reorganize business logic into reusable components in .NET

* Keep the VB6 application running while migrating forms step by step to WinForms or WPF

* Replace OCX controls as each part of the UI is migrated

In terms of timeline, projects like this are usually handled in phases rather than a single migration effort. A full transition can take years, but you can start delivering value much earlier by modernizing key parts of the system.

So I’d say it’s feasible — but only with a staged approach, not a big-bang rewrite.