Refractor SQLGateway Class to Linq

Currently the SQLGateway class is the most confusing and difficult file in the entire system to manage. Unfortunately, it is also the one files that every other file must interact with as it is just as the name states, the gateway to the database. I have held off on this for some time as I wanted to make sure I understood as much as I possibly could about what was being done and what could be done instead.
Here are my conclusions:
1. This class was developed with the intention of abstracting the data layer from the business layer. This is a fantastic idea, in that it can provide a means for reusing queries, and provide a central point of change should the system ever need to be ported over to another DBMS such as Oracle. This follows the spirit of what we as programmers have been taught to do, but were never able to accomplish since the very beginning.
2. Though the idea of providing a single point of change should we use another DBMS is here, it would be impossible in practice to actually accomplish the needed changes to 6100 lines of code along with the other supporting classes, interfaces, and stored procs in any reasonable amount of time.
3. This highly overblown abstraction makes it extremely difficult and time consuming to add new features such as new objects/tables or even new fields as there are about 10 places that need to be updated for each,
4. When the system was initially developed there was obviously a decision made that dictated that all forms of CRUD (insert, update, delete, and select) would be implemented for all data objects. I find this to be a security risk, but beyond that it is very unnecessary. Perhaps the SQLGateway class was generated, and not to be edited by hand, it sure seems so.
5. These standards and techniques were developed to support a .net 1.1 application and thus are subject to review as many years have passed and the app is now under .net 3.5
6. .net 3.5 offers a new technology known as linq or language integrated query. This new data access methodology, provides a 1-3 line interface to the database through ORM (object relational mapping). This interface also provides a parameterized approach which is the number 1 reason for using stored procs, as if additional programming is needed ala a stored proc it still offers these as methods od the data object it creates. Behind the scenes linq creates a data class to mode each entity/table in the database, thus providing the abstraction called for in the 3 tier environment.

I plan to use linq instead of and in place of the current data model wherever possible, Since this application is already quite developed, meaning there is already a large system in place, and the team and myself are all a little new to linq, I plan to implement a 4 tier environment. 1 UI layer (already provided), 1 business layer ( already provided), and 2 data layers stacked. The first will be the existing SQLGateway class and its supporting cast. The second data layer will be interacted with through the first. This means all the existing data methods in the SQLGateway class will remain, and will return what they always have, however inside them, as time permits, I will adjust them to use linq instead of the traditional stored proc setup. This change, along with removing unneeded methods to update, insert, and delete system table data will in my calculations reduce the size of the SQLGateway class by 50%, increase productivity among our team, and still offer every bit of the value of the old model.