IF COVID taught us ANYTHING is that scientist rarely agree when they don't want to agree. What I mean is this. From the first data that the CDC posted many data scientists tracked projections and posted the results to have nearly everyone say they were wrong. I watched at virologists who had 1000's of case studies under their belts get slammed as quacks. I too ran the same calculations and came to the same conclusions and lost respect for people who just discounted the math out of hand. Roll forward to just this year when the real final numbers came out and nearly all of the people who were mocked and dismissed were right. The numbers told us then and tell us the same thing today the difference is now people agree. We assumed these statistics, from the majority, were from people, with a high understanding of the math. Turns out the majority were wrong and the few got it right.... So the question to me is Does knowing Calculus make you a good data scientist? NO emphatically not.

There is no doubt that C# is a solid move, provided that is in your skillset. If not vb.net is not going away as fast as everyone says. It was supposed to be gone in 2010,2015, 2019, 2022 and there are still MANY that use it. I have a friend who converted all of his work to C# and started his own business and nearly all the work he does is vb.net, not conversions. just vb. So until everyone makes the switch it will exist and probably till the end of my lifetime.

Having written and rewritten many programs in the last 35 years I can honestly say that without looking at the way you code I can't tell if the converters will work or not. Even current converters like Telrik have issues converting C# to VB.NET have issues. The one thing that is 100% certain is this. If you review what you used to do and compare it to what you can now do you will probably get rid of a large portion of old code that is no longer needed. If you worked in VB6 before .net and then you opened, closed, parsed files the old fashioned way either in binary or text. You can now ditch nearly all of that code lets face appending a line of text to a file used to take 10 lines of code now, 1 maybe 2? Splitting and parsing lines are now inherent, so is mid$ (now substring) and there are lots of new features to just the string object. vb6 had Drag and Drop nightmares .NET a breeze. My point is the GUID may or may not change but the majority of code behind it probably won't take long to deal with side by side. If you run a conversion and it fails then you have to discover and repair code you didn't write and that sucks. I rewrote a utility yesterday because it was built in 2001 and updated, but not rewritten in 2003. I opened the old code on one side the new on the other and reviewed it. The classes I had written had very few issues and with a few minor modifications those were done in less than a 1/2 hour. The rest of the time I spent dumping old code I no longer need and, I added a barcode class I had built about 5 years ago. In short I have a new tool that is 10 times faster, more capable and easier to use for the users. I would say if you have a conversation system you can test it but then look at the code. If you don't understand it, rewrite it. If it fails, rewrite it....or just rewrite it. And don't believe those that say VB.NET is going away soon. They have said that for 15 years and it is more common than you know. The old man in Illinois

Preach Brother Preach. No Code means NO Repair when you need it NO UpDate when you need it and LOTS AND LOTS OF UNNEEDED AND UNWANTED OVERHEAD!