Upgrading from SQL 2008 to SQL 2012

One of my clients was upgrading from SQL server 2008 to SQL server 2012.  I want to describe some of the items to look out for when migrating.  In this case, the client had already installed a new virtual environment so the infrastructure was in place.   Now what

1. Freeze all changes on production - At some point you are killing yourself if you are trying to migrate one set of reports, packages, and jobs that are consistently changing.   
2. Analyze what packages are currently being used and what packages can be sunset.  Analyze what jobs can be used and what jobs can be sunset.  If any of the jobs send data to another system, attain the contact name for that data for testing after migration.  Analyze what procedures you currently use and what can be sunset.
3. Determine who the business users of the reports are.  Analyze what reports are being used and what can be sunset.
4. Create your timeline.  (Remember that not all jobs are created equal.  Some jobs have 1 step and others have 101 steps.  Don't overload one developer with a one step job to the same timeline as the developer with the 101 step job.)
5. Allow time for testing by peers of the jobs,packages and procedures.
6. Also note that SQL 2012 is not as forgiving on package performance as SQL 2008.   In 2008, you can have a package that performs 50 tasks and it works just fine.  However in 2012, the packages need to be broken up into fewer tasks.  Suffice it to say, that you need to allow time to peformance tune the data warehouse cycle.   Some of this testing has to happen in production.   
7. Allow time for Pre-UAT by your IT team
8. Allow time for UAT by the business teams

Best of luck in your migration/upgrade.   As a follow-up, the upgrade to 2012 is great for the business.  My clients business users love Power Pivot and this also opens up some Power BI capabilities as well for Sharepoint solutions.