Tracy, this sounds like a monumental undertaking. As for documentation etc- the joy and hurt of VFP is that it has proven possible to evolve apps over a decade without the rewrites forced on users of other tools, often leaving a vast array of undocumented code that works well unless you mess with it!

I don't fully understand the app, but in your shoes I'd take a helicopter view of overall functionality, separating modules into commodity and niche groups. Niche is where you'll find the advantages that matter. If possible the commodity part should be sourced cheaply elsewhere. For example, web stores and inventory systems are cheap and carry heaps of fully documented functionality to which you can add bespoke niche modules to provide your unique advantage. You'll save $, and somebody else will be maintaining the commodity part while you focus on what matters.

One other issue: "perfect is the enemy of good". ;-) There is a siren call for developers to write it from scratch rather than relying on somebody else's "rubbish", because that's the only way to get exactly what you need. But that's also the most expensive way to proceed. Take a look at a new luxury Audi vehicle: it shares running gear and controls with VW and Skoda vehicles, because it simply isn't worth the extra cost of creating uniquely Audi parts for everything.

I'm sure I'm preaching to the converted ;-) but I thought it important to document these matters as a matter of balance. Whether it is worth rewriting in C# will be *hugely* affected by the above. Example- what if you discover a database-agnostic PHP project that has 80% of what you need, with easy hooks to allow you to add niche modules. Some will shrug and insist regardless that C# is always the way to go or that SP is always best, but these are political slogans and if your firm has already been drawn to that position, you needn't spend too much time on a technical report. ;-)