When I was working with the U.S. Navy, we had a circumstance where we needed to convert some forms because we were changing from one particular DB to another, and both products had their own proprietary form structure. We found the specifications for building form descriptors for the target system and wrote some code to place form controls by iterating through the forms, for each form iterating through the controls, and essentially translating one set of forms to another "form language." That made the static part of the form. We were also able to build the simpler linkage specifications, too, though sometimes we had to do a little touch-up if there was any type of animation or dynamic nature to the forms - like control buttons appearing or disappearing based on data conditions. Considering that we had over 240 tables and a LOT MORE than 240 forms, the automated conversion was quite a timesaver. I also had to do a conversion of a data "backup dump" of the tables to an importable version of the live data. Turned out that we were able to do the complete migration over one long weekend. Down Friday night, up Monday by mid-morning. With SEVERAL runs to the local coffee shop.
I can describe it but can't publish it because it was code done "for hire" which made it the property of the U.S. Navy, and they have not relinquished any rights on that code. Nor could I take it with me.
In any case, if Access is the source, then the trick is merely to learn how to build the forms for the destination utility and how to manage the linkages to data, because Access has everything you would need available as a format or data property.
Unless, of course, I totally misunderstood the goal here.