I have ported several older VB6 applications to the .NET framework, all of them with almost no documentation, from that experience I can I give you some recommendations. First, let me say, getting rid of VB6 is IMHO a legitimate goal, however, if getting rid of old VBA code (using Excel or Word as VBA platform) is worth the effort is IMHO debatable, since VBA is still well supported for these platforms.
Anyway, if you are really going down this route, I heavily recommend the following points:
1. Dont rewrite, instead: port!
You wrote "I can reduce the locs by 50% at least, just by using modern libs and language features (C#)". By this, you already made the typical error I have seen so many times, even by experienced devs, which will make your attempt fail if you do not change your tactics. Even if the 50% would be true (which is IMHO way too optimistic), you underestimate the time to get these 50% lines of code as bugfree as the original code is. To my experience, if you really rewrite the program from scratch, you will be approximately 10 times slower than by porting the program in a 1:1 manner. See also this older blog post from Eric Nelson, which tells essentially the same. Make sure you also read Joel Spolsky's famous blog post about rewrites.
Porting means, you bring the original source code with as few modifications as possible to the new platform. For this, do yourself a favor and don't use C#, use VB.NET, even if you are surely convinced C# is the "cooler" language. Fact is, C# and VB.NET are almost equally powerful and equally supported by MS, but VB.NET is way better suited as a porting target from old VB6 or VBA programs. Porting will allow you to get most of the program correctly transferred to the new environment with a fraction of new bugs, even if you do not understand every undocumented detail in the old code.
I also recommend to stick back from "modern libs" when there are older, mature libs available which are much more similar to the ones your old program uses now. For example, porting a VB6 GUI to Winforms is by orders of magnitudes easier than to rewrite the GUI using WPF. And libs like DAO or ADO are still available for Windows, there is no need to switch to the very different ADO.NET immediately. If you think switching to a newer library will bring really bring you benefits, do this later - follow the old programmer's wisdom - first make it right, then make it nice.
2. Build a good regression test suite for everything where this makes sense, and build it beforehand, using the old program for producing the reference data!
This can be accomplished even if you do not know the whole purpose of the legacy code. We did this more than once before starting to port, and it saved us so many times from introducing unexpected bugs that I can definitely say it was always wort the initial effort.
3. Plan for porting in small steps, and replace parts of the old program in production by the new one as soon as possible.
With 250K LOC, I am sure there is no chance to replace the old program by the new one in a big-bang fashion. Of course, how to accomplish an incremental replacement depends heavily on the structure of the old program and the use cases which it supports, but in any program of that size, chances are high you can find parts which can be replaced and deployed in isolation. The DotNet stack supports several features to make such a transition more smooth, like easy development of COM components with the .Net language (so you can embed them in your old VBA program as a replacement for the parts aleady ported).
Every part you have successfully ported and brought into production is
a part for which you do not have to maintain the old and the new code any more in parallel
a part for which you get valuable feedback from your users about how well it works with the new technology stack, which helps you to port the next portion of the code more correctly and to estimate the remaining work better.