Best of luck. Especially when you're going to upgrade 2 or 3,000 sites to the next major release.
Another big stumbling block I've noticed when hosting large numbers of drupal sites is that drupal uses a very large number of database tables (>50, sometimes >100) to accomplish relatively simple stuff causing big problems on the database servers.
If you host only a single site 100 tables is no big deal but when you have large numbers of small sites this becomes a real bottleneck.
I believe recent versions of drupal are a bit better behaved in this respect.
The next major release of Drupal (7) has a fair number of improvements towards semi-automated maintenance and upgrades. Most of these leverage off a command line interface called drush.
Also, Joomla, Drupal's closest analog, has a comparable number of DB tables per site. The problem is more likely with prevailing conventions in certain open-source CMS design, than with a particular CMS. Drupal at least lets you share strategic tables across multiple sites.
"The problem is more likely with prevailing conventions in certain open-source CMS design, than with a particular CMS."
This is my understanding of the issue. I had some experience with Joomla back when it was Mambo, and my impression was that a huge number of the tables represented metadata and configuration of various kinds. It seemed like there was an almost fetish-like desire for everything to be configurable from a web UI, and a very heavy price was paid for this flexibility in the backend.
Compare this with a product like PunBB, where it is much more opinionated, and some aspects of the configuration can only be altered by editing key source files. For example, to add or remove emoticons from the bulletin board or edit the curse-word replacement list, you have to edit an array in a file somewhere.
Which may seem like a pain, but the end result is that you save on a big complicated admin screen that will only get used once or twice per installation, and for every subsequent pageview, you're just pulling stuff in from a file rather than a DB table.
Another big stumbling block I've noticed when hosting large numbers of drupal sites is that drupal uses a very large number of database tables (>50, sometimes >100) to accomplish relatively simple stuff causing big problems on the database servers.
If you host only a single site 100 tables is no big deal but when you have large numbers of small sites this becomes a real bottleneck.
I believe recent versions of drupal are a bit better behaved in this respect.