There is no reason to transfer the queries and doing so will cause SUBSTANTIAL work as you rewrite your application to use unbound forms.
To convert the app, use the upzising wizard to transfer only the tables and then link them to the app. Choose the option to add TimeStamps to all tables. This is a system field and is used by SQL server when it gets an update to determine if someone else has updated the record between the time you read it and when you are updating it. If you don't include this column, SQL server compares every column of the replacement record with every column of the stored record to determine what needs changing. Of course back up before you do this because it does change your database. You should also make sure that your table and column names are suitable for SQL Server. If you've used good technique and not used special characters or embedded spaces and have avoided reserved words, you won't have any errors. Run the wizard once to get a feel for how it will handle your tables. If you get errors, delete the server database, delete the converted app and go back to your backup. Fix the problems, make another backup and try again. I've never had to do this more than twice but that's because I understand the things that cause problems and avoid them in all applications, not just the ones I upsize.
Once you are happy with the upsize, you'll need to review your DAO and ADO code. You will need to add dbSeeChanges to many of your .execute and .OpenRecordset statements -
Set rsMember = qdMember.OpenRecordset(dbOpenDynaset, dbSeeChanges)
This is needed to tell SQL Server to return the value of the identity column (autonumber) to Access.
The other thing you'll need to look at is how your forms work. With an SQL backend you absolutely do not want your forms bound directly to tables or even to queries with no selection criteria. If they are, they just sit there sucking data from the server until all rows have been transfered to memory on your computer. This could cause your DBA to threaten you with bodily harm for using all this bandwith unnecessarily. People who have slow Access applications think they can just switch to SQL server and make it better. Not so. Access is actually faster but we digress. The whole object of the switch is to reduce the data footprint of the app and the only way to do that is to optimize your queries. Make sure your forms select the absolute minimum set of records and columns. If your forms currently rely on filters rather than queries with where clauses, you'll need to modify the forms.
And finally, review your queries. If you use UDF's (user defined functions) or VBA functions, they cannot be directly translated to SQL so Access will need to process them locally. If the functions are in the Select clause, that is no problem, the query will be sent to the server sans functions, the data will be returned, and Access will apply the functions locally. If the functions impact selection of rows, that becomes a problem. In that case, rather than sending the query to the server (Access attempts to make all queries "pass-through" by the way), Access will request all rows from all tables involved and run the query locally. This should be avoided at all costs!
Most of my applications end up as SQL Server or some other RDBMS but all can swap a Jet or ACE back end by simply relinking the tables. That is the power of Access.