see also System.Data.OracleClient namespace discontinued?
(Firstly don’t panic yet, System.Data.OracleClient is not being removed by Microsoft yet, however it is not
In addition to what others have suggested you could consider using the Provider pattern and Oracle's ODP.NET.
The customer should install odp.net and the Oracle client on there machines. You should not deploy it. Your application will find the needed Oracle dll's in the GAC.
Have you looked at alternate Oracle providers like devArt's dotConnect? This driver, as an example, is 100% managed code, supports many advanced Oracle features, provides Entity Framework support (that will come some day in ODP.NET, I'm sure).
There are a bunch of other features (like ASP.NET provider model support) that we didn't get until the ODP.NET 11g release. Pretty liberal licensing and reasonably priced. Also comes with it's own profiler, if I remember correctly.
In their tests, performs favorably compared to ODP.NET. I'd love to point you to something open source but, in my experience, once you've bought into Oracle as a database, you've already accepted the fact that you'll be laying down some cash for your database-related tooling.
There's a big difference between being deprecated and being removed.
If you're just using the subset of functionality that is common to both SQL Server and Oracle, then you should be fine moving through to ASP.Net 4.0 and continuing to program how you do currently.
Using something like EntitySpaces, would let you be relatively provider-agnostic. (it uses OracleClient in it's DAL)
Completely agree with Philippe about Oracle's client software being a pain. I've lost track of the number of times I've installed it and hated the experience. Give me MySQL, SQLServer or even Access in preference.
(Actually, I take back the Access comment) :-)
Would using ODBC for both be feasible?
As long as you do not invoke an ODP.Net object, you don't need to install ODP if you only access SQL Server.