SQL Server Redundancy without Client Application Changes
Clustering:
For minimal changes to your client application clustering is transparent, you wouldn't need to change a thing.  Although it will require the most work to setup.  To go from a stand-alone installation which you have to a clustered setup, this will be a lot of work.  You'd basically have to build a new clustered instance &amp; move the database across.  You'll also need shared storage to make this work.

Mirroring:
With SQL Server Standard you are stuck with High Safety mirroring which can mean a performance hit. Good news is that you don't need shared storage and you should be able to build a new 2005 instance and then setup mirroring. Bad news is you'll  need to change your connection string to include a fail-over partner if you want to have a seamless fail-over.  This also only fails over the user database, so you'll need a process to manage moving/synching SQL Agent jobs and logins.

I wouldn't recommend using SQL Server replication for redundancy. 

You might also want to consider log-shipping. This would be a lower-complexity alternative to mirroring although failover is only manual.