We’re running around like rabbits in my project these days migrating 2010 solution en-masse over to SharePoint 2013. Some are upgraded to the 2013 look and feel, while some heavy WSP based ones are kept in 2010 mode for the time being to keep cost down.
The 2010 farm is using FAST search and here’s a small list of things which will not necessarily work when you restore 2010 sites using Core Search Results web parts as part of the solution.
- Search index location for the web parts should be hard coded to FASTSearch, if it’s set to LocalSearchIndex or Default refiners will look and act weird. (See this post)
- If you have multiple web parts on a page, the ones set to use the non-default query id, will pick up the refiners from the default web part.
As an example image a result page which shows documents and people. You want to search for people and documents with the same query terms. When you click a refiner for documents, you do not want this to affect the people web part as those refiners might not exist. When setting a core result web part to use another query id, this just works in 2010, but when moving to a 2013 farm it does not.
It’s solvable but you need to use some reflection like my FQL enabled web part (code at http://spsearchparts.codeplex.com/) which I wrote about in 2011. Need some pointers ping me :)
- If you have copied refiner URL’s like ?k=%2A&r=servicearea%3D%22ARIBVGVjaG5pY2FsIEFkdmlzb3J5C3NlcnZpY2VhcmVhAQJeIgIiJA%3D%3D%22, which have the FAST values base64 encoded in them, they will continue to work, but you might see double up of refiner values in the web part.
The reason for this is that the refinement value has changed format in 2013 and wraps the value itself in a hex encoded format, so we actually end up with a double encoding, and the web part will fail to highlight the correct entry. - Metadata like O&G, which in FAST was stored just like that without spaces is tokenized into O & G with spaces in 2013. So if you have code filtering on properties with & in them you need to replace what the search filter looks like.
Summary
Migration is not necessarily easy, but fortunately for Microsoft not too many companies ever installed FAST (my guess), so the caveats on a migration to 2013 was no big concern. Also if customers spend the money to upgrade the UI’s to 2013, you would re-write everything anyways, and would not have to be concerned with all of this.
For this specific solution my initial migration estimate took a huge hit for sure, but the TCO was still lower digging into the weirdness, and I got to use some of my experimental code written for the FAST book.
That said, I hope this is the last time I ever ever ever ever ever have to touch FS4SP in a migration project again. I’m not a masochist by choice.
#FTW
