Start by documenting every report using the built-in Access documenter. It does reports. This will tell you everything you wanted to know (but were afraid to ask) about the number of controls on each report, from simple lines and label boxes to complex data types. Once you have that enumeration, you can begin designing the next round of reports under the .NET framework because at least you will have an exhaustive list of what you can see right now. (Somehow, the idea of rebuilding the reports from such a list makes the word "exhaustive" more relevant.)
Now, if you know ahead of time what your SQL Server structures will look like, and if you are willing to be really innovative, ...
It is possible to read the design of a report. Reports are in the Documents collection. If you open the report in design mode from VBA code, you can step through the report's collection of Controls to get position, type, binding, and features. Don't forget that the collections of controls can be found in the SECTIONS of the report even if there is only one section, DETAIL.
You can then generate VB source code that would have the same general effect because you should be able to define the dimensions and placement of each control from what you read from the report. Remember, this is only the source code you are generating. You might have to go back and tweak it to assure proper linkages. But this would go a LONG way towards getting you started. Be warned that this won't be a "pleasant little exercise." It will be tedious as all Hell and will take an incredible attention to detail. However, if you have a lot of reports, the effort might be worth it. As a learning experience, it would be great. (Some folks facing your task would probably say, "Oh, great, just what I needed right now - another learning experience.")
I believe I have seen third-party software for this purpose but I must admit it has been a long time ago and I don't recall the details. Perhaps a Google search for Access Report Migration would be helpful?
