Hi again,
First of all, why are you moving to InfoPath? Is it because it supports XML and can easily connect to Web services? If so, good. Now, regarding "coding considerations", InfoPath validates the form using XML constraints and validation rules, so you don't need code for that. What you will need code for is doing things that aren't supported out-of-box in the InfoPath filler form. For example, copying repeating data from a secondary data source to the main data source; or uploading an attachment or image to a document library and repacing it with a link; or generating a globally unique identifier (GUID), or countless other things. Fortunately, we have a common library called qRules that you can inject in your forms whenever you need to extend them. It contains over 130 of the most commonly requested feature extensions. The good news is that it's inexpensive and you can use it in all of your forms so you have a common library that you don't need to worry about maintaining. Many of your forms may not even need it since you can do a lot with InfoPath rules. Of course, you can write your own code independently or alongside of qRules. It's just .NET programming - VB.NET or C#.
Are you still planning to map the data back to the same Access DB?
More later,
P