What does "bring it up to date" mean?  You need to ask them for the specifics.  They may think it means one thing and you take it and another.  Do they want to upgrade Access version?  Reduce file size? Add functionalities?  Or "trim the fat", whatever that means (again ask for specifics)?  Needless to say, you need to do what they specifically require, first and foremost.  I'm sensing that you feel like you should delete some of the queries.  In this early stage, the last thing you should plan to do is delete anything.  Get their exact requirements first.

Sorry, Kevin they did give me a lot more specifics, and bringing it up to date basically means there is more data they wish to track and there is data they no longer need, which I told them I would suggest not to delete any data they have. there are form changes they would like to make.
I will be working off of a Backup and before I delete anything I will test it thoroughly. I was looking for suggestions on using a Query or the SQL statement as the RecordSource for Forms, and Reports. Mainly if it's a query for just one form and not being used anywhere else.  They do have Office 2021 and the Access DB has been working fine but not meeting all their current needs.
And eventually will want to make this available to 4-6 users to enter data.  Right now 1 person at a time does their work, then the next person does theirs and so on.

It used to be that saved queries run faster than SQLs because saved queries are compiled and optimized.  But on today's superfast PCs, my experience has been that it hardly makes a difference, in most cases anyway.  But there are some tactical advantages of using saved queries as record sources over SQLs.  Such as...

If the record source of a form (or report) is a saved query, and in the form's properties or VBA code, you add a filter, then you have access to the data in both the original unfiltered recordset and the filtered one:

Original unfiltered recordset:    CurrentDb.QueryDefs("MySavedQuery").OpenRecordset
Current filtered recordset:     Form("MyForm").Form.Recordset

But if you use an "on-the-fly" SQL statement as the record source, you can only get a recordset of the current, possibly filtered version.  This may sound a little too nerdy, but you never know if you ever need that recordset in your coding.  

A more common advantage of saved queries is in the case of online data retrieval from, say, a Winhost SQL Server database, in which case you likely need to use a lot of saved queries called "passthrough queries", which are queries that Access doesn't run, but "passes" to the online server to improve performance.  But if you put a bare SQL as in the record source, it can only run as a Jet-engine query.  To put a passthrough query in the record source, you have to used a saved query.

Regarding deleting anything in your database, it is only worthwhile to do it if storage space costs you $$$, as in the case of online storage.  The cheapest Winhost plan only allows 500 megabytes of SQL Server database, and in that case you really have to keep your table sizes in check.  If you have Access DBs locally stored on huge hard drives, you usually don't worry about file size unless and until hard drive space shortage becomes a problem.

When it comes to removing queries and putting the SQL in your forms directly that's something that I definitely recommend once you get to that point in your learning of how to build databases. But you have to be very careful going back and deleting older queries because you never know which objects might need them. Always make good backups. But generally if it ain't broke don't fix it. If you don't really need to get rid of those old queries then there's no reason to have to delete them. They don't really take up much space in your database.

Thanks for the great info, I always great useful info when I come here. My membership has paid for itself many times over. I'm not planning on removing any of the items from the project till it's been fully tested and in production for a while. (But) that will be a long time from now.  Right now I'm planning more to implement the SQL inside the form to new things that are added and like you say "if it ain't broken don't fix it".

Again thanks