What a great opportunity. Except the time frame is not reasonable. Having said that it might be possible.
My personal advice. Don't get too creative on data types in SQL Server. I wouldn't create bit or money fields (just 2 for example), if I could avoid it.
Most of your simple Access ShortText columns will probably be fine with SQL Server varchar(rightsized). But (rightsized) takes TIME to analyze. In some cases I have determined this by querying large amounts of data in Access for the max length - then adding 20% to it, for example. This is in lieue of proper information from the business processes, which is, of course, safer. The "max length + padding" method is only as good as if you have significant amounts of realistic data to query. If you are truly uncertain what is proper, just give them something large, varchar(4000) or something. This approach may be roundly criticized in dogmatic SQL camps, but if space is cheap and time is short I am not sure how many other options you have.
Most of your Access Long Text columns may fall under the above approach too, but you can always use varchar(max) if necessary.
I have come recently to be sold on using nvarchar instead of varchar in SQL server, all else being equal, because Unicode is the codepage of the future, and in cases where downstream apps that connect to your SQL database are - slowly but surely - becoming more to prefer nvarchar, but this may be a nitpick you don't need to worry about now. I am not entirely sure how nvarchar plays with linked Access table so you might research it.
If I were you, if you have time, I would re-imagine all your checkbox columns in Access as pratically anything else you can in SQL - possibly varchar(1), intended to take 1, 0, and--if you previously allowed triple state and it works with your form/query logic--nulls. If you feel that LESS programming changes will be required in Access by making it a SQL numerical column with 1 and 0, then go that route. Whether in Access or SQL, I have always preferred to keep data, data, and not use features that mix data and presentation conceptually. Keep life simple.
Your Access Number (long) columns can probably go into a SQL int column.
Your Access AutoNumber functionality can be constructed as an int identity(1,1) in SQL. Obviously the (1,1) in (1,1) won't have any effect. When you migrate your data to SQL server, you migrate the AutoNumber column from Access into the identity column in SQL, after FIRST setting identity insert on, on the SQL table (then back off immediately afterwards).
For date columns in Access, I would usually stick with simple datetime SQL columns. There are more options now than there used to be, but it never hurts to store a timevalue so err on the side of caution. And the more creative date related datatypes are probably something that you don't need and will cause more gotcha's than they will additional useful features, especially when linked back to Access.
For currency columns in Access, I usually use something like decimal(19,4).
For migrating your data, you have options. One thing that has worked for me for amounts of records <=65000, although seemingly unsophisticated but it works! - is this: Create your SQL table with your perfectly matching column layout to your Access table. Link it to Access. Open your Access table and Select all records. Copy. Paste-Append into your linked SQL table. This is a very unsophisticated approach but in some cases I found myself worrying and fretting about all sorts of fancy recommended ways of doing this, while the Paste Append approach can sometimes be done in minutes. One problem: Access allows date entries that are nonsensical to SQL server. You may end up with a small number of records as Paste Errors, and those can probably be handled manually. You could also create a query for the Copy/Paste, excluding dates that might exist in Access but be nonsense to SQL server. You could also possibly export table data from Access to text files, and then use SQL import/export wizard...or possibly even use the wizard for transfer directly from Access, though I haven't had much luck with that, but if you have all the right drivers, it might work. Of course, there is always an Append query from Access-local to Access-linked too. But if you do that you might end up with less informative fallout information compared to the Paste Append. The advantage is you would have an Append query constructed to work on all selected records, and a corresponding Select query for excluded records to be handled manually.
In several past jobs I have written VBA code to loop through TableDefs, evaluate DAO field types and max lengths, corresponding to my chosen SQL datatype replacement, the code created DDL ready to be pasted into SQL server. I wish I had saved it, though it only takes a few hours or so to write if you have a pretty good idea of what your prefered SQL types are. If you had more time I might attempt this for you, but it has a strong dependency on your personal datatype preferences and I doubt would be widely accepted as anything 'universal'. Maybe. But that's a thought you could do.
As for expectations to SQL server performance. It is said don't expect SQL server to make up for poor design, lack of optimization, etc. While I would agree with that, it's still quite likely you'll sneak in some undeserved performance improvement even if that is the case.
My main joy in migrating an Access back end to SQL server is to start leveraging all of the SQL side things. You can then join to well optimized (and maybe even materialized/indexed) Views. You can create high performing, lightning fast stored procedures and execute them via pass through queries. You can create table level constraints, now finally exposed and documented in the plain text of the object's ddl, rather than buried in some clunky Access data macro or validation element. Your stored procedures can raise custom errors--although I've had varying success in whether/when those are passed back to the calling app when it comes to the calling app being Access, but you can even approach this through table-driven error inserts and selects.
If you have poorly named Access columns, that is something you'll have to decide the approach on. Any migration like this is an excellent time to stop and correct everything, but obviously creates a cascading amount of work on the front end. SQL Server is pretty forgiving (more than Access, I think) when naming things like Date and Name, and you can always correct those things in the future as well. I believe several AWF and UA senior members have created various tools to help rename objects--99% sure.
I've said a lot that might be critiqued by others with more experience with me and I am fine with that - helps me learn too. My main takeaways from these experiences have been that unless you're a SQL server guru, keep the datatypes simple. Unless you have the time to learn the deep science that it will be when later writing code against those datatypes, it's a good idea for many if not most of us to keep it simple. My SQL tables usually involve only 3-4 datatypes (with perhaps more varying lengths, null constraints and defaults), and still there is plenty to learn about handling the interplay of those (implicit conversions, rounding, mathematical results, padding, comparisons) properly. There is a whole spectrum of possibility as far as choosing the "precisely perfect" SQL datatype--from on the one extreme using a blanket approach, to on the other extreme where a week of research is used on each one. I'm just saying wherever you land on that spectrum, there is a tradeoff, the wider your base of datatypes, the wider your subsequent care, handling and learning will need to be as well.
If you have time to write some VBA code to loop through your tables and create T-SQL ddl, and you have a lot of tables, to me that is well worth it - gives you a starting point.
Long post - one of my favorite exercises.
