Re: "I know a few companies that consider secondary systems to be critical and will actually fail over, and then run the other system for a few months, failing back to then retest the primary system. In this case, there really isn't a primary and secondary system, but rather two systems that can work, being alternately used throughout the year."

This is the nearest to perfect kind of DR solution to ensure business continuity in the event of a failure, whether catastrophic or not.

Often DR solutions are set up at the DB level but never tested, so in the unlikely event of a failure, a lot of time is expended making the DR work and sometimes it doesn't.

I experienced such a situation recently. The site operated its apps through multiple instances. A single instance failed to restart after a sqlserver upgrade. The database had been replicated via log shipping, so one would think that the app could have been reconfigured to the standby database. The app was from an external vendor, who denied all knowledge of the installation, which had been done by a previous sysadmin, who liked multiple sqlserver instances but not documentation. Despite technical support from Microsoft, we couldn't repair the failed instance. There were only 2 users and there were higher priorities, so the vendor was called in to handle the problem.

All the other more business critical apps had log shipped databases, but similarly failover had never been tested and there was willingness to devote time/resources to do this.

Assuming that systems will fail and configuring, operating your infrastructure accordingly is a great attitude and will pay dividends in virtually seamless business continuity, which when all is said and done is the name of the game.