Access Behavior With SQL Backend

I'm currently researching on how to best migrate from Access back-end to a SQL backend, and was able to find wealth of information on how well Access can play with various SQL servers, how ODBC drivers are implemented, and how JET handles queries to backend. If this helps matter, I'm considering using MySQL as a backend.

That said, there are some gaps in my research that I'm hope someone will be able to fill in for me.

1) I have couple of queries that may use Access's custom function not otherwise supported in SQL servers. If I based the query on otherwise executable query, would JET be able to pass the sub query to SQL, and get the recordset and apply the next query using custom functions without any problems?

2) In general, DAO is best when you're using JET, but ADO is best for ODBC. I'm not clear whether it's possible to use a mixture of ADO and DAO, provided I've disambiguated the library (which I already did anyway) to make even efficient use of recordset. For example, I'd use ADO to work with data from backend and once it's bought over here, switch to DAO for faster handling by JET. Is that possible *and* advisable?

3) I found lists about limitations or problems that may arise due to differences between Access and SQL, which is good to know. However, I never found any answer as whether VBA may cause problems with using SQL data. Let's say I have a form that has lot of VBA coding to handle calculations, multiple selection in listbox to be added to a junction table, dynamically changing rowsource for a combobox, whatever that is based on a query that otherwise runs fine with SQL server- will the form still work just as fine or are there going to be any surprises after migrations?

4) Somehow related, if this is supported by whatever SQL server I may use, would I be better advised to use stored procedures in place of VBA for Access forms?

Thanks for your feedback. :)