Isaac and I disagree yet again. If you have the upsizing wizard available to you, it is the path of least resistance. I used it for years until they discontinued it and it worked fine. There might be an issue with bit data types or y/n data types but I never found any others. Otherwise use SSMA. It was broken for several years but I think it is fixed again. HOWEVER, you need to be careful with SSMA because it will change your date data types to something the default ODBC driver won't recognize rendering all your dates as text fields which will be very bad for you. So, BEFORE the conversion, be sure to check the mapping for data types to make sure your dates get mapped to datetime in SQL Server. This is not necessarily the most efficient mapping but it is the mapping that will always work no matter what ODBC driver you have available.
Make sure your source .mdb is clean. Make sure that you have proper indexes defined and all the defaults and properties set correctly.
Sometimes when I convert databases made by others I run into problems with dates because the original developer didn't validate anything so you might end up with 1/10/202 which Access thinks is a fine date but SQL Server balks at. So you might have data cleanup to do.
Usually, I can make a clean conversion in one or two tries. If the conversion isn't clean, I delete the db and start fresh.
Let the client's DBA define the database and backups. This is not your area of expertise. In most of my accounts, I always feel lucky if they let me work with a test server. When I'm done, the DBA takes over and ports the solution to the production server to which I do not want access because this is not my area of expertise despite using relational databases for over 40 years. I develop software. I am not a DBA. I know only enough to be dangerous. I don't want anyone blaming me for a backup not being available if there is a failure that requires recovery and neither do you.
