We were recently tasked with migrating a SharePoint farm from SharePoint 2010 on-premises to SharePoint 2013 on-premises on a brand new infrastructure.
There were many challenges to overcome during the migration, not least of which was to successfully migrate over 30,000 Forms Based Authentication (FBA) users. There were also multiple Publishing Sites to be migrated, which were heavily customised with bespoke branding features and solutions including page templates and customised management tools for simplified administration.
The sites are implemented in such a way as to use the power and enhanced features of the SharePoint interface during editing, whilst maintaining the brand and customised look and feel of the associated public-facing website. Some of the features of the public-facing websites include a responsive, mobile first design with optimised styles to give users the best experience across mobile devices, tablets and both small and large desktop computers.
Having overcome all the obstacles that inevitably pop up during a complex migration of this scale, there was one underlying issue which needed to be resolved. For an unknown reason, the search functionality in SharePoint was unable to index the Content Database of the largest migrated web application without generating a large number of errors. Specifically, we were attempting to address an issue with the error message “The content processing pipeline failed to process the item”. This issue manifested itself as successfully indexing only two thirds of the site’s content, the rest of which produced this error in the Crawl Log.
We investigated thoroughly, and drawing the conclusion that everything was configured as Microsoft recommended, proceeded to open a technical support ticket with Microsoft to trace the issue. After extensive investigation, testing and hard work together with Microsoft, we were still unable to rectify the issue. We had narrowed down the issue to an unidentifiable (and un-rectifiable) problem with the Content Database of the Web Application and we were left with the prospect of potentially having to rebuild the farm.
In order to work around this problem, we rebuilt the Search Service Application and created a new web application. We then proceeded to use ShareGate’s migration tool to migrate the contents of each site, one bit at a time. At each stage, we would correct any issues we found with the search index, often using PowerShell scripting to apply bulk updates. Eventually, we had a fully operational search index and no longer saw any trace of the original error.