On the 2nd of October NIST decided that SHA-3 is the new standard hashing algorithm, does this mean we need to stop using SHA-2 as it is not secure? 

What is this SHA-3 anyway?

The SHA-3 hash competition was an open process by which the NIST defined a new standard hash function (standard for US federal usages, but things are such that this will probably become a worldwide de facto standard). The process was initiated in 2007. At that time, a number of weaknesses and attacks had been found on the predecessors of the SHA-2 functions (SHA-256, SHA-512...), namely MD5 and SHA-1, so it was feared that SHA-256 would soon be "broken" or at least weakened. Since choosing and specifying a cryptographic primitive takes time, NIST began the SHA-3 process, with the unspoken but clearly understood intention of finding a replacement for SHA-2.

SHA-2 turned out to be more robust than expected. We do not really know why; there are some half-baked arguments (the message expansion is non-linear, the function accumulates twice as many elementary operations than SHA-1...) but there is also a suspicion that SHA-256 remained unharmed because all the researchers were busy working on the SHA-3 candidates. Anyway, with SHA-2 doom being apparently postponed indefinitely, NIST shifted its objectives, and instead of choosing a replacement, they defined a backup plan: a function which can be kept in a glass cabinet, to be used in case of emergency. Correspondingly, performance lost most of its relevance.

This highlights the choice of Keccak: among the competition finalists, it was the function which was most different from both SHA-2 and the AES; so it reduced the risk that all standard cryptographic algorithms be broken simultaneously, and NIST metaphorically be caught with their kilt down.

Let's not be hasty: not only is SHA-2 still fine (both officially and scientifically), but SHA-3 is just announced: it will take a few more months before we can get a specification (although we can prepare implementations based on what was submitted for the competition). What must be done now (and should have been done a decade ago, really) is to prepare protocols and applications for algorithm agility, i.e. the ability to switch functions if the need arises (in the same way that SSL/TLS has "cipher suites").
