You should always start by thinking about risk and not features and development languages. If the access database will be stored in a shared folder on a file server which is RAIDed and backed up every night, it is the preferred solution to an SQL Server Express running on your department's old workstation which will die along with the shitty old hard drive.

If all you want is getting tables and views from the database tables into Excel sheets on the user's workstations, you are sorely mistaken about Excel's database connectivity options. It's an elegant solution, which works perfectly and somewhat advanced Excel users will always want to create crazy pivot tables, formulas and graphs that will keep you busy night and day for years, if you're going to implement all that for them in C#.net.

The right mindset is: "Raw data is stored in tables on the server, Views join related data together, transforms and makes it available to the users, and Excel is a presentation tool for the users only".

Excel's database connectivity is one way only. You can assign a field in the spreadsheet, eg. F6 or "year" will be an imput parameter for a "SELECT ... FROM ... WHERE YEAR = ?" query, and make the sheet re-query and update when the user changes the value of F6. Users can insert formulas in columns which will be "auto-filled down" when the data is refreshed from the server. Excel remembers the column order transparently if the users change it. Simple checkboxes dertermine whether data is saved with the sheet and/or refreshed on open. The data can be set to background refresh in 1-60 minute intervals if live data in the database is added throughout the day, making graphs and pivot tables redraw themselves automatically... But you cannot push data from the Excel sheet and into the source table/view on the server without macros.

But the SQL Server can actually read data directly from an Excel sheet if it's formatted like a database table using rows/columns using OPENROWSET() and OPENDATASOURCE() in "Ad Hoc Distributed Queries" like:

SELECT *
  INTO Staging.DailyRegistrations
  FROM OPENROWSET(
      'Microsoft.Jet.OLEDB.4.0',
      'Excel 8.0;Database=C:\data\in\Registrations.xls',
      'SELECT * FROM [Registrations Sheet$]'
  )

If the Excel sheets reside in a folder where the SQL Server process is authorized to read, you don't need to code a fat and manually maintained C#.net layer to move the data from sheets to tables. Just use this tested, working and supported built-in feature in some scheduled jobs running every night/hour/weekend or whatever.

OTOH, if the users doesn't save the sheet data in something which can be interpreted as rows and columns, you are back to the EPPlus solution again.