Installing and upgrading help

I would, personally, change my apache settings to point the DirectoryIndex somewhere else. Just write a little html file with "This site is offline for maintenance...". 

Moodle maintenance mode is too much hassle and/or unlikely to work for a massive upgrade like this. 

Are you implying that you want to do this upgrade on a production site? That is not advisable. Make a copy of your site and do the upgrades on that copy. That upgrade depends on a number of factors and may go smoothly but may also require tweaking and redoing certain steps (so proper backup for each step is strongly recommended).

If your source site is actively used in the meantime, you will work out a procedure that you can repeat with the production site to minimize the down time. I would take the production server offline (like changing its IP address) and put a temp server that displays maintenance msg in its place. If that is a shared service, you can switch directories around, either rename in the file system or fiddle with Apache config (per Howard's suggestion).

I wonder why you want to jump from 1.9 to 2.1. Normally, one jumps from 1.9 to 2.2 and then go directly to any newer (destination) version. One interim stage is needed only for sites using some type of activity (escape me at this moment which one).

Think that for everyone that has done a 'moodle march' it has been slightly different due to when the trigger was pulled to 'march'.   By that I mean, one 'marched' when the highest stable available version was say 2.3.2+ build 20120927 had slightly different experience than others when the build date was later (newer) and Moodle was 2.3.highest.

I maintain a MDLGITTEST directory on a Mac laptop and use it to test git and inspect code.
./WZC/version.php:$release  = '2.3.2+ (Build: 20120927)'
./elis/version.php:$release  = '2.6.5+ (Build: 20140911)'
./gittest/version.php:$release  = '3.0.2+ (Build: 20160204)'
./gittest3/version.php:$release  = '3.0.2+ (Build: 20160204)'
./iomad/version.php:$release  = '3.0.3 (Build: 20160314)'
./mdl30lastest/version.php:$release  = '3.0.4+ (Build: 20160513)'
./moodle18/version.php:   $release = '1.8.14 (Build: 20101214)';
./moodle19/version.php:    $release = '1.9.19+ (Build: 20130513)';
./moodle20/version.php:$release  = '2.0.10 (Build: 20120706)'
./moodle20ngit/version.php:$release  = '2.0.10 (Build: 20120706)'
./moodle22/version.php:$release  = '2.2.11 (Build: 20130708)'
./moodle232/version.php:$release  = '2.3.3+ (Build: 20121123)'
./moodle23git/version.php:$release  = '2.3.11 (Build: 20140113)'
./moodle24/version.php:$release  = '2.4.11 (Build: 20140714)'
./moodle25/version.php:$release  = '2.5.9 (Build: 20141110)'
./moodle26/version.php:$release  = '2.6.11 (Build: 20150511)'
./moodle27/version.php:$release  = '2.7.13 (Build: 20160314)'
./moodle28/version.php:$release  = '2.8.11 (Build: 20160314)'
./moodle29/version.php:$release  = '2.9.3+ (Build: 20160107)'
./moodle30/version.php:$release  = '2.7dev (Build: 20140403)'
./moodle31/version.php:$release  = '3.1+ (Build: 20160609)'
./totara/version.php:$release  = '2.5.3 (Build: 20131111)'

Do know there were things that appeared in site admin menu that later disappeared.
(got bit by that once ... not reading the fine print and hopped too far expecting
the link in the site admin menu to be there, but wasn't. :\)

Case in point ... IF I re-call correctly, didn't certificate disappear for a version or two
in early 2.x?   Then re-appeared.   No matter ... here's something I still find in sites
that have been migrated:
In moodledata course ID directories.  1 is present in all of them ONLY IF site admin had used
front page to upload a file and linked to it in site menu (like the old PowerPoint Player exe).
There were other course ID directories that contained moddata -> an ID number -> an ID number -> a PDF by the same name - certificates that were issued.  Matter of fact, one such site has to keep them cause  there are former students who ask for a copy of a certificate they got X years ago.

That ballons the moodledata directory from what it should be.

I'd leave any old course ID numbers that remain during the 'march' and inspect what remains
after the 'march' - maybe even archive for reasons given above.

Will also share this ... am big on 'marching' via git and taking the few minutes that it takes to
'march' in sequence via a git script combined with admin/cli/ scripts.    Yes, that does take longer, but ...   at any stage in the 'march' one might have to address a plugin or a theme or something else (that indicates that one has taken stock of what
mods/blocks/reports/question types/etc. ... anything NON-core ... that might exist in each Moodle).

During the 'march', most often, only the code directory changes ... 1.9 -> 2 of course the most massive
change takes place ... with all of it.   AT each stage in the 'march' one should check for updates to plugins and acquire them.  Would use the Moodle UI for this as that's something one would want working well by  the time you get to destination.   That will 'balloon' mdeploy directory in moodledata of course.

Pretty sure that one major issue is related to file system ... 1.9.x->2.2.highest sets all courses/site
to legacy mode and from that time forward it's legacy.  The 'march' does bring across users ... which is good ... but as with all things (yin/yang) it also sets legacy (forever).

It's not been unusual that a site Moodle admin has decided not to 'march' but to install the latest/greatest and then have teachers 'rebuild' their courses.  Teachers learn the new system.   Can provide them a directory for the files they had in their course.   Wouldn't use a 1.9 full course backup to restore to a Moodle anymore.  Won't get users and files are legacy so no advantage in doing that, but what might really get messed up ... quizzes (question banks) etc..

As to maintenance mode ... on/off ... that can be done easily via command line, and, when I do a 'march' is included in my little 'march' script.   Probably a good idea to also purge caches at some point before the next step in the 'march' ... and that would include php opache.  Yes, that slows down the site you are working upon for a while and it takes a little while to build up the cache again ... but it is a major part to Moodle now ... so in affect, you are testing that as you 'march'. :|

Also, I don't deal with 1000 sites at once ... maybe 4 or 5 more like it.  With 1000 sites, think I'd
be tempted to try a hyperjump with one first and see how it goes.   With 1000 sites think I'd pick the
sites that had no customizations/addons, etc. and 'march' those first as their 'trip' should have
less issues.   Then take on the sits that did have customizations/addons/etc.. ... one at time.

The servers I help maintain that do have multiple instances, I've now a 'niupdate' and a 'niupgrade' script (ni=non-interactive update=within a version upgrade -> next highest version.   In both of those sql dumps and tar balls of code directories are created before and after update/upgrade.   Separate backupdata script as they are large and really don't change much in updating/upgrading.

Ok ... that's my 2 cents! ;)

'spirit of sharing', Ken