It's not clear that a major redesign right now is correct.
It's usually far less work to mechanistically duplicate the same functionality than it would be to redesign the application at the same time, and that is especially true when moving between two similar languages.*
Even if there are big design flaws, there are also big risks to making changes. Changing the front end may upset/confuse users and lead to more training. Changing the data may have implications for whoever is using it. And then there is the effort required for the redesign.
Porting a flawed design in a different language/environment might be perfectly defensible, if the effort for this is low compared to a redesign.
Take an incremental approach to change, focusing on specifics.
The argument "this application is bad and flawed" may be true, but it doesn't work well when your team leader wrote the application. You aren't going to win any support that way.
Instead, identify specific things that could change. Propose something concrete, and highlight the benefit (rather than the flaw of the current design).
Start with changes that are lower risk (less disruptive to the current design) and as people see the benefit, you might get them listening to the bigger ideas that you have about what could change.
*Whether VB6 and VB.NET are versions of the same language is debated, so I have removed this claim, but clearly the two have a lot in common.