SPEvo13 - COM701 - The full story of a large scale SharePoint upgrade


Published on

Presented at SharePoint Evolutions Conference in London, April 2013

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Why are you upgrading?What are the businesses drivers?It’s new?Out of support from Microsoft?Fresh Start / Rebuild a clean systemAging system needs turning over / new hardwareNeed / want new featuresDo you need to upgrade?Can you achieve new features with what you haveWhat is the ROI?Should you upgrade?You don’t want to get “too far” behind the curveUpgrading from 2007 to 2013 isn’t possible (without third party help)Single step increments are easier than skipping a version or twoCan you upgrade?Is your hardware up to the job for the new version?Can you afford to upgrade?Acceptable Downtime
  • Business Critical / Important SitesEngage site owners early onWork closely with them to make their sites upgradeableYou’ll want to work with them when writing site level test scripts – start earlyIncompatible SitesLarge Lists / List View Threshold issuesSite / Web Templates that won’t be availableSites likely to breakHeavily customisedLarge amounts of contentIdentify those Approaching Maximum sizeUpgrade process temporarily expands Content DB sizeShould settle back to roughly the same size, but some can be larger after migrationPerformance of current environmentIf search isn’t indexing quick enough in our current platform we know we need to pay more attention to that in the new platform
  • The desired EnvironmentCloud / on-prem / hybrid?SBS, single farm, multi-farm?Virtual / physical?Third Party Components (eliminate / standardise / increase / straight migrate)Upgrade OptionsIn PlaceDBMigrateEtcThere is really only one option you should consider!! – DBMigrate!Architecture / Infrastructure Design No different to designing a brand new platformNew version has different requirements / constraints / boundaries and limitationsLearn from your last architecture / infrastructure projectPlan for growth If you are investing in an upgrade then you are seeing value, so growth should be at a higher rate on the new platformPhased Vs Big Bang (Phased is preferred)Shorter outages for end usersEasier to manage in case of any rollbacks/defectsValidate newly provisioned platform for performance, stability before bringing more loadEasy handover to operations team for supportShorted period of PGLS SupportLess issues to manage after migration
  • Move Site Collections between Content Databases as requiredCreate free space in DatabasesGroup like sites High risk sites together...or separate!Can deal with all together with a high priority teamSeparate out to reduce risk per databaseLow risk / unimportant sites can be "dumped" into the new environment and dealt with later
  • Start upgrading customisations- Don't underestimate how long this can take-Straight upgrade / embrace new features- New platform probably won't be available at start so "make do"- Build test scriptsUpdate branding / UIif you feel you must!KISS Script environment build (and document manual steps)Repeatable and controllable processYou will be rebuilding the farm(s) many times to keep testing defect fixesForms part of your DR planYou'll get good at building your farm from scratch Good change control post-base-build will keep you DR plan validManage build deltasTest upgrade (build scripts, manual steps, database migration / upgrade) see what breaks
  • SP2007 -> 2010 - Content Query Web Part DataMappings column instead of CommonViewFieldsTitle / Description fields not propagated
  • SPEvo13 - COM701 - The full story of a large scale SharePoint upgrade

    1. 1. The full story of a large scaleSharePoint upgradeCOM701Mark Stokes
    2. 2. Mark Stokes Red Plane www.redplane.co.uk mark.stokes@redplane.co.uk @MarkStokes Microsoft Consultancy in the North West– Interested in Photography, MountainBiking, Snowboarding and a bit ofSharePoint / Office365
    3. 3. Migration Steps Deciding to Upgrade Audit “The Process” > Migration Weekend Post Go Live Support Launch Party!CommunicatePlanPrepareTestImplementValidateandRemediate
    4. 4. Deciding to Upgrade Why are you upgrading? Do you need to upgrade? Should you upgrade? Can you upgrade
    5. 5. Audit Sites Identify Business Critical / Important Sites Incompatible Sites Sites likely to break (heavily customised / large) Customisations Internal and Third Party Content Databases Obtain Site Lists for each Content DB Identify those Approaching Maximum size Infrastructure Pre-upgrade check Anything else that you think is important
    6. 6. Plan The desired environment Upgrade Options Architecture / Infrastructure Design Migration Approach Phased vs Big Bang
    7. 7. Prepare Housekeeping / content tidy up Ask site owners to look at their own sites Archive / delete unused or old sites Reducing the amount of content tomigrate simplifies your project Move site collections between contentdatabases as required
    8. 8. Implement Start Upgrading Customisations ASAP Update Branding / UI Script Environment Build Build your Defect Tracker Test Upgrade – see what breaks Site owners - UAT Repeat until you are happy
    9. 9. Defect Tracker Start your defect tracker! Categorise defects– Priority– Pre / During / Post / Training– Remediation documents– Group defects into duplicates / repeats - Train support to solve theserepeatable fixe Caused by platform changes SP2007 -> 2010 - List View Threshold Limits. SP2007 -> 2010 - Content Query Web Part Try to fix / re-architect these sites in your existing environment beforeupgrade There will probably be similar changes in SP2013... Check thedocumentation Identify false defects Kerberos causes RSS feed web parts to “break” Test URLs cause hard coded URL references to "break"
    10. 10. Continuous Improvement Fix defects Blow away Test Environment / Content Rebuild Test Environment If testing farm build scripts Migrate Content into test environment Test Update Defect Tracker Start again
    11. 11. Search Index Options Rebuild Search Indexes fresh? A lot of content could take a long time Pre-Index old system Freeze index Re-index after migration
    12. 12. Migration Weekend Old Production Read Only Period Backup databases Restore databases into new Platform Perform “During” fixes Change Kerberos SPNs Make DNS changes – YOU ARE LIVE! Perform High Priority “Post” fixes Production Read-Only period for platform stabilisation Start Crawl content on new platform Exit New Production Read Only Period Perform Lower Priority “Post” fixes
    13. 13. Post Go Live Support Fix new defects Train users in “new features” Post Go Live Party!
    14. 14. Thank you for attending!