1. Test Upgrade Name Title Company 9/18/2018 Microsoft SharePoint
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Upgrade Cycle Learn Prepare Test Implement Validate Upgrade methods
New capabilities
Downtime mitigation
Prepare
Document environment
Manage customizations
Plan upgrade strategy
Make items upgradable
Test
Build test farms
Use real data
Evaluate techniques
Find issues early
Implement
Build/upgrade farms
Deploy customizations
Minimize downtime
Monitor progress
Validate
Troubleshooting
Upgrade event failures
UI/UX issues
Data issues

3. Test Upgrade
Building Test Farms

4. Test Environment Considerations
Be careful of impacting live environments from test ones
External data connections modifying live data in bad way
E.g. deleting an item thinking it is only a test environment causing production impact
Running database impacting commands against live databases
E.g. Test-SPContentDatabase
Test environment hurting performance of shared SQL servers
Best to run using different SQL servers (not just instances) for production and test
Try to prevent/minimize URL changes
These can cause issues you only experience in test environment
Can do this by using same URLs and testing only from machines with host file changes
Actual machine names should be different though to prevent AD issues
Database names should stay the same if you want to validate scripts
Per above, you shouldn’t be using the same SQL servers for production and test

5. Test Farm Methodologies
Use real data and copies of entire databases
To prevent flaws occurring only in production
Use similar hardware if possible
To identify trouble areas
To determine upgrade performance
Test a copy of everything, not just a sample
Will give best equivalent performance data
If a parallel farm will be used for upgrade try using it for testing first
E.g. use new farms as test before doing actual production upgrade
You only really know what you have tested
The unexpected lurks in the databases you didn’t test
Gives excellent indication of actual upgrade performance and issues
Use production processes in test environment
Make sure to pave test environment before doing actual upgrade

6. Test Upgrade
Evaluation Techniques

7. Upgrade Testing Cycle Test Environment Learn Prepare Test Implement
Upgrade methods
New capabilities
Downtime mitigation
Prepare
Document environment
Manage customizations
Plan upgrade strategy
Make items upgradable
Test
Build test farms
Use real data
Evaluate techniques
Find issues early
Implement
Build/upgrade farms
Deploy customizations
Minimize downtime
Monitor progress
Validate
Troubleshooting
Upgrade event failures
UI/UX issues
Data issues
Test Environment
Implement
Build/upgrade farms
Deploy customizations
Minimize downtime
Monitor progress
Validate
Troubleshooting
Upgrade event failures
UI/UX issues
Data issues
Learn
Upgrade methods
Downtime mitigation
Performance
Understand issues

8. Expectations From Testing
Understand upgrade methods and processes
Know what works
Know what the outcome will be
Understand performance and downtime mitigation
Should have a good guess on downtime
Should know per database how long upgrade will take
Gain experience and confidence in troubleshooting and validation
Know your enemy
Where it lurks
What it looks like
Know how to make it right again

9. Test Upgrade
Testing Processes

10. Testing Processes Confirm the upgrade plan you’ve chosen will work
Does it do what you expect
Does your upgrade plan provide the right outage mitigation
Are there any gaps in the process?
How would you roll back if you need to?
You did take a backup, right?
Validate any scripts and commands used
Scripted processes are more repeatable
Make sure a script you may have used in 2010 or earlier is still valid
Parameters change, and sometimes how they work changes

11. Test Upgrade
Performance Testing

12. Upgrade Performance Testing
Actual hardware + actual databases = reliable results
Measure sequences and actions
Parse individual upgrade logs for performance data
Use multiple upgrade runs per database for more accuracy
Collate multiple runs results to get likely performance per sequence/action/database
Determining upgrade performance per sequence/action
Parse upgrade logs
Collate time spent per action instance per log
Collate time spent in each sequence per log
Separate out database upgrade times from site collection upgrade times
Mainly look for min, max, and average

13. Post-Upgrade Performance Testing
Confirm against pre-upgrade performance goals
Ensure your new farm is not going to give less than you expect
Look for SQL responsiveness at load
Disk queue length
CPU and memory usage
Look for SharePoint servers responsiveness at load
Requests Per Second (RPS)
Page Load Time
Initial clean request, loading scripts for first time (PLT1)
Secondary requests with scripts cached at client (PLT2)

14. Test Upgrade
Testing Service Applications

15. Service Applications Testing
Consider various states you may be in, not just initial or final state
2010 farm connected to 2013 services
2013 farm connected to 2013 services
Different version farms for different services
Verify in all possible states you will use in advance of production use
Helps to find security, configuration, compatibility, and even performance issues
Service upgrade can be complex due to number of services
Script the service upgrade process whenever possible

16. Test Upgrade
Testing Customizations

17. Deploying Customizations
Ensure solutions are deployed
Consider that legacy solution deployment with default will result in being only in 14 directories
Deploy legacy solutions to 15 directories if required using CompatibilityLevel option on Install-SPSolution command
If not using solutions ensure deployment of:
Custom Master pages
Custom JavaScript
Custom CSS (including those for themes)
Custom workflow actions must be included in actions file
To ensure rendering for larger lists, confirm large list query throttling settings

18. Testing Customizations
Pay special attention to visual and behavioral issues
Test in both 14 and 15 mode
Look for language/resource loading issues
Manually deployed customizations resources may be in 14 global directory
Won’t get loaded since only new version global directory is used
One versions resources may prevent others form working
E.g. 15 version resource file same name but doesn’t include 14 version resources
Fixes to this require rework of customizations
Validate upgrade impact on customizations
Confirm that customizations do appropriate upgrade tasks if required
Ensure that they don’t block site collection upgrade

19. Microsoft SharePoint Server 2013
Test Upgrade
Conclusion
Building Test Farms
Evaluation Techniques
Testing Processes
Performance Testing
Testing Service Applications
Testing Customizations
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

20. Q&A

21. 9/18/2018 1:20 PM
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.