So many factors can affect SQL Server speed that it is difficult to say what the problem is. SQL is a resource hog, and if you have any other processes on your server, that will slow things down, as well has not having good data normalization, the right columns indexed (or too many indexes), insufficient hardware, sunspots (just kidding about the last one).

Depending on the amount of data munging you have to do to the text files, you may want to look at skipping the .Net piece and load things in via SQL DTS packages. If you have minimal transformations to make you may be able to speed things up significantly. ADO.Net simply adds one more layer that the data has to go thru. This is, of course, totally dependant on your business requirements.

Conversely, you might find that VFP makes a great alternative as a data loader for SQL. VFP's string manipulation is extremely fast (to be honest I have no comparisons for .Net) and you can use OLE-DB to move the data over. Just because you are moving to SQL doesn't mean you have to use .Net.

The bottom line is that, as mentioned by others, speed by itself is not a good reason to move to SQL. You may actually take a performance hit, but if you need better security and large table capacity this may not be an issue. Getting the best performance out of SQL provides job security for a lot of DBA's!