• I doubt there is anything that complex written. There are variables for your environment, and most people don't do upgrades across three versions and document this. They usually do one.

    You can look here: http://www.sqlservercentral.com/search/?q=upgrade+checklist&t=a&sort=relevance

    There are some pieces you can use to examine this, but you'll need to do work. For the advantages and disadvantages, you'll need to look at changes in R2, then 2012, then 2014 to get a complete list. Some of those will matter for your environment, some won't.

    For hardware, you need a baseline, though the versions will alter that slightly, it's good enough. Get performance on current hardware, and then make some guesses on extrapolation with new hardware. That's really hard, and I don't have a good way to do that. I'd guess you want a similar number of new cores and more RAM if you can, and as fast, or faster, disks.

    Do you test now? If you don't have a test plan for patches, service packs, app upgrades, how could anyone spec out a test for the next version? You should have this in place. What needs to work? Everything you run, all packages, reports, etc., you should have a way to test those. If you don't, you'll have to do that. What I'd recommend is that you load a backup of production, and then have a script that adds 20-50% (or more) data to the database. That gives you load and performance. After all, data grows.

    This should be some plan that your organization maintains over time, for all patches and upgrades.