The question you should ask yourself is how is the salesperson know that the feature will cost x developer-days of work. Given that even good project managers with years of professional experience cannot often tell that, such data coming from a salesperson seems extremely... speculative.
According to my experience, salespersons usually don't make estimates, but guesses about how much is too much for management or customer: if management is ready to pay 50 man-weeks of work, but will absolutely reject 75 man-weeks, let's tell that the feature will take 70 man-weeks while being ready to renegotiate (something which is out of question for a real estimate) down to 55 man-weeks.
On one hand, you have estimates done by IT experts telling something like:
According to this specific audit, we are wasting $8 000 per day using an outdated technology compared to similar projects of similar size which use newer technologies. It also appears that it will take from 50 to 80 man-weeks to migrate the whole code base; during this time, there would be no new features released. There is also a 10% risk that migrating a specific component may result in 20-30 additional man-weeks of work.
On the other hand, you have guesses done by salesmen, based on their leverage when negotiating with the person they need to convince.
It's all about how influential you are in your company. Communication is key here, and this is where salesmen usually win over IT professionals when it comes to explaining the benefits of a feature to management (or a customer).
Note that if in the past, your estimates were quite precise, you gain reputation and influence. If your estimates were always wrong, management would probably ignore your proposals.
As for the estimates, it is extremely difficult to make a valuable one here, since there are a huge number of parameters to take in account. Among others:
Do you actually know how skillful is your team in C# compared to VB6? Is it based on actual measurements or just guesses?
Have this team developed large projects in C#? Do they know the tools they should use (IDE, debuggers, profilers, etc.)? Do you need additional licenses (which, in Microsoft's world, mean thousands of dollars per machine)?
Is the current project totally clear and you can guarantee that there will be no surprises when migrating? Is it straightforward to rewrite everything, every feature, or would there be surprises?
Do you have the infrastructure which supports C#? What about continuous integration? What about your build server? Style guides? Static checkers?
In production, are servers (if this is a web app) or customer PCs (if this is a desktop app) able to run the version of the .NET Framework you are expecting to use?
But the most important thing is to know why do you want to rewrite everything. What is the problem you are trying to solve through a rewrite? A loss of productivity? How do you measure it? How do you show this loss of productivity to management?
Once you have shown that you are wasting, say, $8 000 per day because of VB6 (which means that you'll save $8 000 per day once you migrate to C#), how do you explain the benefit of holding every new features development and focusing on a complete rewrite? What's the benefit compared to progressive rewrite where you migrate your components in small chunks one by one, while shipping new features?