You really don't want some type of automated conversion anyway. The reason is that you need to CHANGE how you done some these things to work with the architecture change that occurs when you move from one development system to another.
An automated conversion is probably not much worth it since so often how things were done in the previous system will be done differently in the new system. For example when people came from DOS based (text screen based) FoxPro applications to Access there was two significant changes the developer had to make:
1) No record numbers in Access
FoxPro (which was a dBase compatible clone) had its roots in being a singer user file based database system. So this was system designed from the ground up to operate on your personal computer. This meant the file and programming system used sequential records from a file on the hard drive. This model was much like punched cards data processing. And I should point out there's nothing wrong with this type of model, but the software approaches and designs you used for punch card data processing is somewhat different then compared to interactive multiuser systems.
What is SIGNIFICANT and most important here is on a conceptual level when you write software inside of Access then record numbers or so call record order as a conceptual idea that as you write software is NOT relevant. However in Foxpro assuming record order was a legitimate assumption. This is an architecture change. I remember back in early 90's that in many forums one the FIRST questions from long time Foxpro developer asked is:
How come access does not have record numbers like Foxpro does?
The answer was simple and that answer is/was Access considers data a big huge unordered bucket of data. In other words if you wanted some order to your data, you had to add something like an invoice number, perhaps even a time stamp, or something else. For something like a sub form as a general rule you can rely the auto number, but that auto number should never been seen by the users. No matter what, you had to use a SQL query that SAYS what order you want.
Another important detail is if you add 10 records to a table (even in single user mode), if you then retrieve those 10 records from that table, you can NOT assume the record order will be the same as when you added them. In other words if you need a particular order, you have to sort that data by some column. This is an assumption that FoxPpro, or people who used FORTRAN and punch cards could always assume. Such assumptions cannot be made when using Access. In fact this assumption cannot be made with any modern server based system such as SQL server.
However this "lack of" record order assumption was SIGNIFICANTLY important later on down the road. This "assuming" means that THEN your WHOLE Access design was now based on assumptions that ALLOWED easy conversion to multiuser systems OR that of client to server (both need this assuming).
So your software designs could never say go to the next or previous record (based on record number) since records are now a mumble jumble of records being entered by different people. The next two reocrds in that table (or previous ones) might not be yours! So keep in mind that while Access allows you go to the next/previous record inside of a form, it NEVER does so based on record number but ONLY on the data that's been CURRENTLY loaded into that form. In FoxPro you would often move around by actually using command that said go to record 4 in the table.
In Access we don't say go to the 4th record in the table. You might say go to the 4th record in some data that we pulled from a table into a form, but that 4th record has absolutely nothing to do with the actual physical fourth record in the table. A small change, but one that was required for multi-user systems that we started to use 10 years later (so the smale change in software produced beneifts 10 years later!).
As a general rule this architecture or philosophical concept of record order in a table is not a very big deal at all for most of the software you write, but if you needed to use SQL server later on, then it was a big deal. And I should point out that since your software is written using SQL in mind, then at least in this regards you are in good shape.
However for those that wrote applications over 4 to 5 years based on this simple record order assumption, it would have to be completely RE architectured for multiuser environment or even for Access.
I should point out that FoxPpro eventually became a brilliant object orientated client server development tool, but had to go through a significant metamorphosis than what the original architecture and designs that a typical FoxPro application had.
2) Event driven programming
In these older text based systems you tended to write one large major startup program with a main menu system included. Choosing a menu option would then perhaps branch to a section in the main program or perhaps branch out and call another portion or part of the application. However to its credit, FoxPro and a good number of dev tools did have some event type of setup, but they were not ideal. It best to re-do much of how those screens and UI will work when droping text based UI anyway - this is VERY much the case with new touch based and gesture based UI wew now see such as smartphone or iPad.
In event driven programing we as a general rule don't have that large startup program. And we also don't have a large code base for the main menu system. In event driven programming you have code that RESPONDS to a user click. Or you have code that responds to a record save. Or even navigation to the next record.
So in event driven programming you click on a button then a rather SMALL bit of code would respond to an event by the user (in this case a mouse click). So this type of programming is what we call event driven programming.
All of a sudden, your application is now not being driven or run by one big large main program, but in fact is a whole bunch a little tiny small programs stitched together by event driven code.
For people coming from an DOS based environment, or even QuickBasic, GW-basic or even many of the older text based database systems, then having one large startup program with some menu system was common.
And having a large program to "edit" one data entry screen was common.
Now such designs are turned upside down in which your menus and click events were now going to run and call code. Thus these very small routines would THEN call other bits of code to allow the application to run.
The main reason for this architecture change was the introduction of the mouse and the graphical user interface. In other words when looking at a data entry form, in place of tabbing along to the next field in a complex data entry form the user can now click on many different things and even click on the menu bar. So they can click just about ANY place on the form. This means that having one big program to run and maintain the form data entry is/was not possible. If your code was waiting for input in the Company field, then how could code be run when the user clicked on a menu bar option? Since the user could do many things in many different order than what the original programmer would anticipate then we need a different way of writing code.
At the end of the day with a GUI then code branching became too complicated for the developer to anticipate. Hence the concept of event driven programming was born to solve this dilemma. In other words our code now runs and responds to the users actions and our code is not waiting for the next user input sitting in some line of code.
Again this was a small architecture change, but many developers struggled with this conceptual change in approach to software development. On the other hand all of these changes occurred in the early 90's.
The next big change the course was object oriented programming. Access does allow you to build class objects, but it is not a full OO system.
Today the next big challenge and change and architecture is the ability to build web based systems. Again a zillion changes occur due to having "solve" different programs for the developer. Access 2010 allows one to build web based systems now, and this conceptual and architecture change is a GREATER challenge than that of learning the new macro language we have for developing web forms with Access. So a "change" in how you design software has to occur again.
I should point out that these major changes in the industry happen about once every 10 years or so.
My point of all of the above is, even if there was some automated conversion system, it really would NOT work very well because the architecture of the systems are very different. You would be handicapped by all of the old assumptions.
I also note you been around asking about using using Access in various Access forums for what about two years or even more now? You seem to be looking for some magical silver bullet that will solve your problems. There is not one!
At the end of the day you need a sit down and obtain some basic Access skills or hire someone. You need to learn the system you going to use and THEN come up wth a desing that works with Access and "is" for Access.
I should point out that the desing you choose for Access would not necessary say work with vb.net either. So don't try and take an existing desing and put a square peg in a round hole. What works in one system in terms of UI will NOT work in other systems.
I think you been fooling around much too long here. About the only good part of delaying so long is you now have to consider if you want to adopt a set of tools that allows some web integration with the application?
Office 365 works great with Access web publishing, but for complex mature applications, I think the web side is somewhat weak (but you can write hybrid applications with Access 2010 now). Here is an video of Access web in Action:
http://www.youtube.com/watch?v=AU4mH0jPntI
In the above, I swtich to running the applicaiton in a web browser. This app was 100% built in Access, including table trigger logic and code (no 3rd party tools or coding system was use - ONLY Access was used).
Considering technology right now, perhaps you have this run on iPads as they walk around in the store? There a lot of new choices here for software, but if you sit around for another 2-3 years, then you be looking to use something other then the iPad and some "other" new system.
You can certainly write your applications as more "touch" friendly in Access. However some of the new gesture based actions do not transfer to web. For example, we cannot disable keyboard input in a combo box, and this ability would REALLY help the Access application running on an iPad if we could. The reason being is when we tap or hit a combo box on iPad then it pops up on the screen the soft keyboard and we do NOT want this. And some of a really slick gesture date pickers etc. don't translate to web on the iPad (they do want you to write native apps after all!).
