Throw all of that out. Doing an upgrade in one step is possible, but really is only workable if you can get a clean upgrade from, say, a clean environment. Most prod environs I've ever seen have not been clean enough to tackle with the one step upgrade.
Restore data directory and DB back to your working 6.0 system.
Start a 6.1 "cleanup" SQL script to collect all of the clean up steps.
Then use 6.1 to upgrade the environment to 6.1. Look at the logs during the startup phase, that will tell you something about any data failures that occur. If something fails, add the fix to the cleanup script, restore back to 6.0, apply the script and then upgrade to 6.1 again.
Wash, rinse, repeat. When you finally get through the 6.1 upgrade without a failure, backup your data dir and DB because you'll need it for the next round.
Repeat this process again, create the 6.2 "cleanup" script to collect your changes, try the upgrade to 6.2, for failures update your script, restore, apply the script, restart the upgrade.
Again, wash rinse repeat until you get done with the 6.2 upgrade.
Wherever you do the algo 6 update, be sure to capture the backup after that and use it as the starting point for whatever upgrade point you're building to.
The problem you run into with "multi-version" upgrades is that the upgrade time is basically the sum of the separate upgrades. This would be fine if you got a clean upgrade out of the gate, but most of the time (at least for me) there's some sort of upgrade failure that forces the restore and restart of the upgrade process.
For a thought exercise, let's say the upgrade failure occurs on the last upgrade step of the last version of your multi-version upgrade. Since the total time for a single pass is T1 + T2, you have one restore to clean the data and restart, so your overall runtime is going to be 2 * (T1 + T2) or 2*T1 + 2*T2. Now if you break it up and capture the intermediate backup, when the same failure occurs you can restore back to your midpoint so your total time is T1 + 2*T2, basically saving you the T1 time.
That's only for a single failure. If you can imagine multiple failures occurring during the latter upgrade phases, you can see how the time accumulates because you'd have to restart back to the beginning in the "all at one time" approach. Breaking it up is tedious and a lot more manual steps, but if T1 and T2 are long times (like hours for each), you can see how the detailed, manual process will actually save you time overall.
As far as identifying and resolving errors, you have to look at and interpret the exceptions you encounter. It will likely point to a table or index that is causing the failure, hopefully it will include some PK detail or something that you can use to identify the bad data. Find the bad data, add cleanup SQL statements to your cleanup script, restore the database and apply your script and see how far you get on the next cycle. That's the best help I can give you here.
Come meet me at
Devcon 2017 or
2017 LSNA!
