The GPL, in all its variants, is a redistribution license. It simply doesn't apply at all if you don't redistribute code. It may apply in the future if, some day, you decide to make a product out of your application, but not now.
This is going to be a large and very involved project. I've been responsible for migrating Access databases to .NET many times, but never on this scale. I agree that a gradual approach will probably be the most realistic. Trying to take on everything in one shot is an easy way to fail.
As in other answers, the first and most important step will be to move everything to SQL Server. While doing this, document the database if this hasn't already been done, and identify areas for refactoring if they exist. Access databases that grow to meet evolving needs often have data models that can be improved upon when looking at the big picture.
Next, identify modules of the application that are "self contained". Because this is a do-everything database, there will probably be modules of it that are nearly completely disjoint from each other. After having these disjoint pieces, identify one of the smaller modules that has the most to gain from being updated, and take it on first.
While migrating to .NET, don't just do a simple 1 to 1 copy of the application. Gather input from users to identify pain points with the current application. You want your first migration unit to be a huge success to gain the complete buy in from everyone else.
After you have the first unit done, look at what happened in terms of challenges, difficulties, etc, and use this moving forward.
One thing that I would strongly discourage would be to implement partially working modules (ex: "we migrated the CRM, but features X,Y,Z are not in the new system yet"). This will cause users to quickly become frustrated from having an incomplete system when the old one to them was "perfectly fine". This kind of development may work fine for other domains, but not in businesses where users see "nothing wrong" with the old Access monolith and don't understand the migration needs.
Best Answer
The only fee to using an Access database file is if you also use the full version of Microsoft Access. If you app is built with Visual Studio, deployment should be pretty easy to include your datafile and necessary drivers (latest version of windows should have them).
The latest format is for 2007/2010. This is a very good article explaining conversions, benefits, etc. http://allenbrowne.com/access2007.html
As long as your app doesn't have multiple users sharing data, SQL Compact is an alternative (See Tom Morgan's Answer), but you would have to adjust your code. If you have users that need to sync to SQL Server from their occasionally connected desktop/mobile app, SQL Compact has many features to make this easier.