First, there is no "real SHA-3" yet. In a few months, NIST will publish a specification which will define unambiguously what SHA-3 is. Unless there is a big blunder somewhere, we can predict that SHA-3 will be bit-to-bit compatible with the specification of Keccak as submitted for round 3 of the competition.
Then there is no reason to replace SHA-2 with (future-)SHA-3: neither scientifically (SHA-2 is not broken, far from it; and, for performance, Keccak is not terribly better than SHA-2, and often worse, depending on the architecture), nor administratively (the NIST people themselves posit that there is no need to replace SHA-2 with SHA-3).
There are reasons to replace MD5 and SHA-1 with SHA-2 (or SHA-3 in the future) but these reasons were already valid last week and you should already be doing it.
Algorithm agility is an important quality of protocols -- but that's a question of protocol design. People who are qualified to design security protocols already know it, and the other should refrain from designing protocols.