More planned upgrades, yes. Moving to static HTML caching for anonymous users, and more front end servers to handle the page rendering load. We do these slowly and carefully so don't hold your breath :-)

I think you've probably been misled slightly by the term server. I'm sure Pieter will correct me if I've got this a bit wrong, but I don't think the processors were upgraded with this exercise, only the storage devices. In which case, the internet presence of wikidot.com would not have been affected, so no IP address issues resulting here.

As I recall, RAID disk arrays have built-in data replication so that any disk can be hot-swapped in the event of a failure without losing access to the data that was on the disk in question. Also, the DBMS is most likely mirroring the whole database continually to a separate array anyway. So if one mirror is unavailable for some reason then the DBMS can still operate on the other one. Having features such as these built into the design of your architecture then enables you to make such hardware changes seamlessly, on the fly. It's pretty clever stuff and it all happens, like you say, as if by magic.

So as Michal explained: this is a back-end issue, it does not affect the front-end servers (which serve the Wikidot.com domain), and although there are IP address changes, they are internal to the cluster.

The real magic is to create multiple parallel databases and switch in real time from old to new, without losing replication, or current connections. Michal says it was "simple" but that is deceptive. This is the kind of operation that takes real skill and experience. Then, of course, it's simple.

One more reason why we're all happy that Wikidot.com exists, it takes over all the stress of managing our data. For me as a user, when I see this kind of smooth upgrade, I'm more confident than ever that everything else (such as replication) is also done properly and that in the event of a disaster (meteor hitting the data center, or whatever), I won't lose my sites.