SharePoint Migration

Introduction

To better understand the methodology of migrating content from one SharePoint system to another, we first need to understand the concept of migration itself: why organizations do it? How much time does it take? How can we minimized the risk?

SharePoint has received regular upgrades every few years, and the many improvements over its tenure have resulted in multiple iterations of the platform. Because of these improvements and the expectations of today’s users, businesses are compelled to tackle a SharePoint migration more often.

Why Organizations Migrate To Sharepoint 2016 / Office 365

Deeper Integration

• SharePoint 2016 takes a big step forward with its integration with other Microsoft products, most notably Office 365 and OneDrive for Business.
• Users can safely store their files for others to access them, which will be compatible with whatever program they use.
• It also ties in with hybrid SharePoint deployments for organizations that have chosen (or plan) to move portions of their infrastructure to the cloud.
• MS has recently introduced FLOW and Power Apps which provides better support and integration with other Microsoft products like Outlook, One Drive, SharePoint, office, etc. It provides ready templates which we can easily use for the business requirement and integration.

Infrastructure Efficiency

• SharePoint 2016 offers many features, but some of the most impactful for IT are MinRole and Zero Downtime Patching. MinRole simplifies deployment by automatically configuring services that are needed for that individual server’s role.
• This means that administrators can concentrate on farm level services instead of the individual service level. The added benefit is that the configuration of services across the farm will be optimized for performance, reliability and scalability.
• Zero Downtime Patching lets IT teams patch their infrastructure without having to shut it down – a huge win for organizations that place high value on end user productivity

Mobile Experience

• SharePoint 2016 delivers mobile experiences on a range of mobile devices. This means employees can work while on the move and increase productivity.
• While access to content is still controlled by IT, giving users the freedom to work or collaborate on that content on a wider variety of devices helps them better engage with their work.
• Integration with OneDrive for Business takes this a step further by allowing users to access their content from anywhere on any device.
• Microsoft now supports responsive and new design using communication templates for SharePoint sites.

Pre-Migration Analysis and Planning (Get Ready to Migrate)

Four Key Questions for Planning

• Is all of the migrated content actually being used?
• Content analysis is a good way to not only understand the volume of content, but also which content is (and is not) being used.
• For content that is no longer being used, moving it to an archive or resetting it to “read-only” might lessen the total migration load.
• What access, roles and permissions are in place?
• These need to be documented fully, on paper, prior to migration. They will form a big part of your test plan.
• How much downtime is the business willing to tolerate?
• Any downtime affects business and during the planning process, it needs to be factored into the migration process. One way to reduce downtime is to ask that business users take the appropriate amount of time to review content and provide feedback.
• This helps understand what’s mission critical to their productivity and may provide additional insight into setting priorities.
• Can the migration be done from the current version of SharePoint?
• Planners will need to take into account the potential that interim upgrades need to be completed first. Or they need to choose a specific migration path that allows skipping to an interim migration.
• Unless an organization is using a third-party migration solution, moving to SharePoint 2016 from SharePoint 2010 requires systems to be first upgraded to 2013 and then 2016. There is no out-of-the-box support for migrating from 2010 to 2016.

Make a Detailed Inventory of Your Environment

• By having a detailed inventory of everything you have, you'll be able to make better decisions and estimates on the effort of the migration. The more information you have, the easier it will be to plan and respect your migration deadlines.
• Establish an Inventory
• Site Collections
• Sites
• List and Libraries
• Pages
• Custom Solutions
• Workflows
• Content Types
• Site Columns
• Permissions
• User Alerts
• Retention Policies
• Records
• Users and Groups used
• Large lists or libraries
• All les that have a dependency to another le using a URL
• Blocked File Types
• Branding
• Any other UI customizations (JavaScript, altered menus, etc.)

Clean Up Your Old Environment

• SharePoint is all about helping people build what they need to get the work done, but it doesn't mean you still need everything today. Take the time to find, remove and reorganize things in your environment.
• Find and remove “Orphaned Users”
• Remove empty SharePoint Groups
• Put users with explicit permissions back into Groups
• Delete any Unused Content Types, Site Columns and Workflows
• Find sites that haven’t been modified in over a year, and see if you still need them
• Ask users to check-in any document currently checked-out (ensure you migrate the latest version)
• Find large Site Collections
• Break them up into multiple Site Collections
• Find large Sites
• Promote them into Site Collections
• Remove duplicate content
• Clean up items containing too many custom permissions
• Remove unwanted versions from your version history
• Reorganize Lists and Libraries with too many columns
• Rethink and reorganize very large lists

Prepare Your Destination Environment

• A migration is the best time to wipe the slate clean and start over. Make sure you take the time to plan and structure your new home according to your needs. You might not get the chance again for a long time.
• Map your destination's architecture
• Optimize your new SharePoint Servers' performance [At the install]
• Configure all Web Applications
• Check desired authentication & authorization rules
• Back everything up
• Test the restore
• Check the databases for corrupt data
• If any corrupt data: delete it.
• Run a Test Migration
• Highlight any unsupported elements
• Configure your new Search Topology.
• Set SharePoint up to import user imports from any specific sources.
• Map a plan for the metadata on your content.
• Look at your customizations
• If required, convert them to work in the new model/destination (see appendix)

Perform pre-migration analysis

• We have a tool to perform pre-migration analysis on source farm. This tool generates a set of reports which will help us identify issues that can occurs during migration in advance.
• For e.g. site collection with custom list templates, custom site templates, custom features, obsolete site collections, list having larger files etc.
• Most frequently used site and non-active web applications. Start migration with non-active sites and least frequently used sites so it will decrease the incremental migration efforts.

Communicate with Your Users

• Your biggest challenge for the migration is bringing change to your users. For this to be successful, you'll need to make sure they know what's going on and why it's happening.
• Inform your users before starting
• Downtime planned by the migration
• The reason for the change and the value for them
• Possible changes in the environments
• URL changes
• Bookmarks
• Document References (Excel macros, etc.)
• Estimated timeline for the migration
• Create sandbox sites for hands-on previews

Start Your Migration

• The actual migration effort shouldn't be too complicated if you followed the previous steps. It comes down to moving, and dealing with, anything that pops up that didn't show up during testing.
• Workflows
• Complete or Stop running Workflows about to be migrated
• Migration scenarios
• If migrating from SharePoint 2013 On-Premises
• Perform database attach-upgrade to bring everything "as-is". We can use content DB approach for on-premises migration.
• If migrating from an earlier SharePoint version
• Use a third-party tool. ShareGate and Metalogix are two famous migration tools in case you want to do using migration tool.

• Migration from On premises to Office 365
• We use our tool for creating sites, lists and library structure. We also use document sync approach for documents migration.

Migrate all users

• All users should be migrated in destination environment before we start the migration.

During the migration

• Once you have a plan, you can begin to set it in motion. However, it is important not to fall into the trap of rushing ahead when things are in place.
• There are still issues that you’re likely to discover during the process itself, and these can become a lot more challenging unless a high level of care is taken throughout.

• Avoid These Top Five Migration Pitfalls


• Rushing The Process
• Small mistakes as a result of rushed planning cycles can lead to huge, expensive gaps further down the road.
• In SharePoint, data model and taxonomy flaws may not become apparent until weeks or months later, normally when users find issues in production systems.
• The longer it takes to find these issues, the more expensive it becomes to correct them. Take the time to check every detail during the migration to minimize risk.
• Missed Customizations
• As noted in the previous section, performing a complete analysis of all your customizations in your previous environment is essential to ensure that the final SharePoint 2016 environment works correctly.
• During the migration, any missed customizations that haven’t been adequately prepared for may cause a failure. If a failure does occur, plan on sifting through error logs to find out why a migration failed – only to come across a rogue web part or custom site design.
• Treating All Sites And End Users The Same
• Three out of four teams may use SharePoint ‘out-of-the-box’ – with little or no customizations, but treating that fourth team – with their custom workflows, extensive dashboards and customized integration to the CRM system – in the same manner would be disastrous. Why? The out-of-the-box sites should, in theory, migrate cleanly, but the fourth site will need more care.
• Understand the individual needs and requirements of each team, especially your power users (those who depend on SharePoint every day). This is absolutely key when moving custom code to the cloud.
• Going In Without A Rollback Plan And Not Testing
• A good project manager mitigates risks with a solid rollback plan, and the same should be done with a SharePoint migration.
• You may be able to recover from problems caused by rushing the process, not identifying customizations or not employing healthy test practices; but you will not recover (without severe pain) from rollback failure.
• Incomplete Testing
• Testing should not be treated like a check box activity. It should cover as many eventualities and scenarios as possible – planning, or in this case testing, for the worst means not having to “hope” for the best.
• Workflows and Customizations are the obvious things to test but other elements, including security, are just as important. Ensuring security and permissions migrate as expected helps avoid serious data exposure.
• This is especially important if you have intellectual property assets or sensitive data stored in SharePoint.

For Your Custom Development

• Considerations for your Custom Solutions
• Create an inventory of your customizations. Take a look at what needs to be migrated. A migration is open the perfect time to identify what you don't need anymore, and leave it there. Also, make sure you have a good overview of what you have in your sites (WSP, Sandbox, etc.), and if one depends on another. Map it out to be sure to deploy everything in the right order at the destination.
• Are you running any Farm Solutions? The good news is that they still work in SharePoint 2016. However, Microsoft recommends you stop using them. Also, they can't be deployed to Office 365. If you do migrate them, open the WSP and change the target deployment.
• Do you have any Sandbox Solutions? They still work in SharePoint 2016, but as with Farm Solutions, they recommend you to stay away from them. Instead, look at the artifacts within, and convert them to provisioning in the add-in mode. If you are going to Office 365, Office 365 does not support sandbox solutions.
• Considerations for your Custom Solutions (cont’d)
• Pain Points when migration to Office 365:
• Converting any Web Parts you developed to Add-Ins may prove to be difficult.
• If you've built Timer Jobs, there is no real solution when going Online. You’ll have to find new solutions that give you the same result.
• Event Receivers: you’ll also need to find a way to host them somewhere, and rewrite them to continue getting the same result you used to.
• You may need to reconsider how you deploy your declarative artifacts. You may need to do this using an Azure Web App, PowerShell, etc.
• Custom Fields is something you should stay away from. Instead, see if Display Templates can help you display content the way you wanted it, instead of creating a new field for it.
• Depending on your migration method, item IDs in lists and libraries will change during the move. If you are using them in your logic you will need to take that into account.

Post-Migration

• Many people believe that once a SharePoint migration is complete, their work is done. In actuality, it’s quite the opposite.
• To make sure your migration policy stays true, tasks such as cleaning up page layouts, checking links and ensuring security and permissions are in order must all be maintained in the medium to long term (and arguably the very long term as part of ongoing non-migration governance).
• Every SharePoint environment changes with its end users and as they begin to use the environment more, they’ll create new demand.
• Different teams might face new security rules based on their roles and require new governance be applied to their data. One group might decide to reorganize their content in a different way to better adapt to a new business process.
• Company reorganizations, mergers and acquisitions might mean that content from several groups needs to be merged, moved and reorganized within the new systems.
• Before you swing open the doors and let everyone into your SharePoint, make sure everything is ready for them
• Test your Destination Environment
• Ensure all migrated successfully
• Test/Run all workflows
• Check user permissions
• Test your Destination Environment
• Before you swing open the doors and let everyone
• Create a backup of your new environment
• Remove access to the old SharePoint
• Run a full crawl
• The first task in getting users to realize a new level of productivity is the migration. To turn a good migration into a great one, the following tasks should be implemented post-migration:
• If you are using a third-party migration solution, copy alerts from the source to the target environment, so that they do not fire-off events during the actual migration.
• Run any incremental jobs created pre-migration.
• Send automated e-mail to site owners or site collection administrators after the site migration completes.
• Review content with site owners to ensure a smooth transition.

Go live

We need to plan and finalize the go live date and down time for incremental migration. Users use the source environment during migration process so we need to do incremental migration after before go live.