SQL Server replication for off site copy

Based on what you have described Log shipping is going to be the way to go. Log shipping is old school, tried and true.

Replication is pretty fragile, provides massive amounts of room for failure especially when it comes to adding new tables and getting those tables into the replication topology.

As for 2012 upgrade costs they may not be as bad as you think. If you have software assurance and an enterprise agreement that'll save you a bunch of money on licensing.

Log shipping might be "crude" (I prefer to call it straightforward), but replication is complex and, in my experience, brittle. You don't want to add complexity if you can avoid it. You don't want to have to go through some sort of heroics to fix a broken replication setup.

Managing the replication configuration of all of those database would be a bear of a problem. You can't use the forms of replication that would alter database tables, as I suspect testing those changes on 500 databases is a very large project, if not a career, in and of itself. You can start to have performance problems on the subscriber side that require you to start looking at fillfactor, maintenance plans and other, similar complications. What happens if you need to flip over from your primary servers to your "local" secondary servers? Are you going to re-do all of the replication configuration? That's likely to be a big task. If you automate it, that is time spent creating and testing the automation, and then it needs to be looked at when you change those 500 databases.

Recall that all we had for DR was log shipping up until SQL Server 2005. It's not glamorous, but it works.

TL;DR- Simpler is better. Use log shipping.