Regression Testing

I do.  However the focus of my work is a bit narrower than the scope of your question - I'm usually in a development cycle.

In the development cycle:

I start out with the release notes. 

Recompile all rules, looking for deprecation notices.

Then run through the set of functionality for the application being built - following the requirements traceability matrix.
Its pretty much the same as regression testing to a shift in design->implementation.

With an upgraded MST, same process. Release notes, then regression test against requirements.

In an existing application:
Migrate a copy of Prod back to Dev
Tie out between the two environments.

Upgrade Dev

Validate requirements against the matrix

Tie out data with Prod.

Success in repeating this process with QA strengthens the hypothesis that the upgrade is valid before proceeding to prod.

Each organization will formalize these outlined steps. 

I hope this helps.

1. Compare all the artifacts between existing and upgraded environment to make sure that if any any new properties /  fields added to existing. ( we use beyond compare to compare the complete XML code)

2. re-execute the consolidation from the inception and make sure that there is no change in the data before and after.

3. Compile all the business rules and look for any errors, warning in existing environment and make sure that they are same after upgrade.

4. Make sure that all the application functionalities are working same as existing environment ( Reports, WF's CV,s business rules, consolidation, calculation, task manager, batch jobs, data management jobs, openng/closing periods etc...).

5. Let the business test each of the function.