Just about solving my vexing moodle upgrade issues from 2.2 - 2.6

One of my moodle instances has been a problem in terms of upgrading from 2.2 - 2.6.  My past upgrade attempt ended in a lose of almost 2 days of production data because I DID NOT NOTICE a BIG fat problem until about 24 hrs into deployment of the upgrade.  Once I noticed it, I did not realize the magnitude of the problem which was this.  None of my cause backups would restore.  We have hundreds of 3rd party vendor courses that we have backup up and need to be able to restore at various times.  Fast forward a few months and a new test instance and this is my synopsis and test upgrade results.

The problems I have experienced seem to be related to NUMEROUS plugins that were added to the moodle over about a 3 year period.  During the upgrade, I run into various messages about tables already existing.  I cannot afford to lose any data, so while upgrading, if one of these errors is generated, then I have to stop and start over.

The have tried various paths of upgrade .2 - 2.3 -2.4 - 2.5 - 2.6.  2.2 - 2.4 - 2.6 and 2.2 - 2.6.  The moodle doc are sketchy at best about the best practice.

These are my latest findings which have resulted in an upgraded 2.6 instance where my course backups do restore without failure (ye - $#%#$ rah).

Useful things for you to try/remember when upgrading a problematic moodle site

Preficatory steps

backup the live DB first
put the site in maintenance mode
create a test instance to work from
create a separate test server if possible (one step better than a test instance on the live server) - I once, accidently of course, upgraded the live DB while playing with my test instance (thanks to moving the wrong config.php file into the root of the test instance. 
Make a copy of the file structure, in addition to the DB.  copy the file structure and call append pre-upgrade to the end of the folder name.  This leaves your live folder ready for the upgrade and a copy of it as it WAS PRIOR TO THE UPGRADE, just in case.  You can never nave too many just in cases.

Plugins

Ensure you update them prior to upgrading the DB, all of them.  If you are not using an old plugin or add-on, remove it.

AFTER YOU HAVE completed all the plugin updates to the moodle code base - make a copy of it.  I spend probably at couple hours upgrading plugins and returning to the PLUGINS check point in the upgrade.  Fine - I just do not want to have to go through all that again.

My file structure snapshot -

student is the folder being upgraded (where I drag the updated moodle code to)
student-2_6 plugin ready is the result of me updating all the plugin spots with the latest and greatest moodle code for 2.6
strudent_original is the moodle 2.2 code base PRIOR to the start of the upgrade process

When I encounter an upgrade error because some table exists, I an now appending 22 to the end of the table.  This way, I keep the table that was not supposed to exist and its data, since I will probably need that at some point, which ALLOWS THE UPGRADE to continue - by creating the table it wants.  The thing I found today was that after moodle creates the table - it actually populated it.  Which is what we want. 

 A snapshot of the DB after the upgrade (moodle 2.6) using phpMyAdmin - these are the tables that existed - that caused upgrade errors that I appended _original to the end (next time I will use 22)

One final note - when the upgrade complains about existing tables - If that table that is NOT supposed to exist is empty, then I just drop it and continue the upgrade - no need to save anything by appending _original to the end.   Using phpMyAdmin, I can see if the table is empty - note the number under the Rows column.