RE: How well does the converter convert ADO to ADO.NET ?
That's like asking "how well does a person convert ADO to ADO.NET?"
The answer depends how well that person can define "convert ADO to ADO.NET" and how precise they can be in implementing that definition.
Likewise, gmStudio is a programmable software re-engineering tool. It works as well as the user can define and implement his requirements using the tool's customization features.
In either case the quality of the conversion design is critical. However, there is a big difference: a person using the tool can implement the transformation very precisely and very quickly (100s of thousands of lines per minute) where as a person working manually cannot (a few lines per minute plus more risk of human error). If you have "a lot of code" to rewrite, or if you want to experiment with different ways of doing the rewrite, the speed and precision of tool-assisted conversion can be very helpful.
We have a sample of how this is done for RDO to SQLClient here: https://portal.greatmigrations.com/display/GMG/RDO+to+SQLClient+Sample
There is no need to convert DAO to ADO first, the techniques from that sample can be extended and applied to any other API transformation -- including DAO to ADO.NET.
There is also the option of using our ADODB emulation (MigrationSupport.DataLib) like we do for the FMStocks sample.
I would be happy to take a look at what you are trying to do and discuss how we can help.
Let me know if you want to setup a web meeting.