Two, I think, very important questions ...
1. is the platform (operating system) Linux? (if so what distro? Ubuntu/CentOS/other).
2. are you adverse to using the command line - which is really dependent upon #1).
I too have 'marched' moodles from 1.9's to now 3.3's but servers were linux and the first step was to get the code of the 1.9.x to the highest 1.9.highest under git. Used git from that point forward.
You cannot upgrade php to 7.0.x before you get to Moodle 3.0.highest ... so might be wise to put a 3.0.highest step in there ... then upgrade PHP to 7.0.x. Could keep that version through 3.4 but eventually, you will want PHP 7.1.
I have also done the other way .... fresh site installed with git ... then marching the 1.9 to a 2.highest ... using command backups (full course backups) of the 'active courses' and then restoring multiple courses in pre-setup categories of the new site - via moosh. And then one more hop with the restores to highest. Went back later and did the remaining ... not active courses.
Plugins/Themes were something to check at each stage ... not all plugins made the triip to 3.4.x.
A plugin could stop an upgrade using any method of upgrading ... cli via git OR web based. However, using command git one could actually be in the middle of an upgrade that failed due to plugin and correct it, then continue with upgrade.
Other things not mentioned ... tweaks to php ... along the way ... time for a script to run (default 30) increased ... memory a script can consume (128M -> 256M *IF* you can do that). Each time you upgrade the PHP, the settings you had from the older version will be lost and one needs to tweak again.
Tweaks to DB ... max_input_vars, max_packets_allowed ... plus DB character set, collation towards the end ... 3.4 especially.
This is no easy undertaking ... any route you choose. What ever/which ever way you do, do first on a clone of what you have .... and make backups along the way. Big change to moodledata on the hop from 1.9 to 2.2.
The size of your site means you might need remote (ie, another server) to house the backups.
Backups ... not only of code, but DB dumps ... at first, all of moodledata ... when you get to 2.x+-> not much change to moodledata ... but it is something to check along the way. When in doubt ... *** backup *** moodledata as well.
And ... after all that ... one will discover 'legacy' file system in the highest must be used ... cannot turn off ... until a fresh course is made under the new version.
Confusing, huh?
'spirit of sharing', Ken