Now that I’ve been actively involved in two SharePoint migrations from 2010 to 2013, let me tell you what caused me the most headaches and what you’d better not underestimate in case you come yourself to migrate.
I’m not going to talk about refactoring and/or upgrading the code to be more compliant with 2013 except for the extreme situations such as using old legacy SharePoint components. So, most of the comments below are about an “as is” migration and things to consider seriously.
Before going into more details, you certainly already know that SharePoint 2013 ships with two SharePoint roots, has some specific IIS tricks and makes use of two GACs. There is a native support for 2010-like SharePoint sites. One way to migrate 2010 packages is of course, to deploy them in 2010 format. The attention points below are for most of them, only valid when you migrate to the 2013 user experience.
1) Classic mode to Claims
Although, Claims was available as of 2010, many organizations have still 2010 running in Classic Mode, usually with either NTLM, either Kerberos. While this might sound more an infrastructure related topic, here are a few applicative challenges related to this:
- Users must be migrated
You need to migrate users from Clasic to Claims. This can easily be done using powershell. However, once the users are migrated, you need to check everywhere in your custom code if you reference usernames. Why? Because the format of your users will be completely different. It will not be domain\user anymore but rather in claims format. It’s not a big deal but just thinking of it might save you a lot of time.
- No more Windows Integrated security, so no more Passthrough or no more RevertToSelf by default
If you have anywehere server-side components that are calling external web services, backends or whatever, SharePoint will call them anonymously where it used to RevertToSelf by default (or PassTrough with BCS) in Classic Mode.
With Claims enabled, SharePoint will always perform server-side requests anonymously, even when targeting its own web services. So, even if you have InfoPath Forms (dead product now) that call web services, they won’t work anymore. If you are in such scenario, you’ll have to consider working with the Secure Store Service.
If you have webparts that consume web services or file shares etc…all of that won’t work anymore unless the targeted resources are anonymously consumable. Of course, if you are migrating components that were already running in Claims in 2010, you shouldn’t have any problem
2) Custom Field Types
For most of the Custom Field Types I had to migrate, they just don’t work from 2010 to 2013 unless you keep your sites in 2010 user experience and even then, you might have some surprises as you can read here : http://www.silver-it.com/node/155.
So basically,now that the rendering engine isn’t based on XSL anymore but on Display Templates, you have some rework to do on the Custom Field Types.
Note that, depending on your business needs, you could also decide not to migrate some or all of your custom field types and decide to convert the related fields back to their parent type with PowerShell before migrating the content. That is causing no data loss but you’ll lose the functionality of your custom field type of course. For real legacy sites, it can be an option, data is still there and viewable normally using the OOTB field types and forms.
3) XSL – Display Templates
Admittedly, I didn’t have very complex workflows to migrate, however, in the scenario I encountered, the customer had previously migrated from 2007 and the content databases had some old SharePoint Designer workflows. They were never been reedited with SharePoint Designer 2010. If you come to migrate that same content again to 2013, those workflows won’t show up anymore in SharePoint Designer.
To avoid that, you need to republish those workflows with SharePoint 2010 before migrating to 2013.
Since BCS talks to line of business services, you might consider the security aspects highlighed by the first bullet of this list :).
6) Custom Site Definitions
It’s a long time that custom site definitions have been discouraged by Microsoft but as many say, it’s often a necessary evil. The problem of course with this component is that you can’t move the data if you don’t migrate them or you really need some kind of migration tool that will move data from your custom site def based site to a OOTB site def based site.
Where most of the functionality still work, custom site def often need to be reworked because they keep using old features and it turns out that often, your 2013 site still looks like a 2010 site. It’s not a blocking point but you might plan some rework there.Also note that some OOTB site definitions became also deprecated in 2013.
If like me, you already liked to leverage the SharePoint Search API, you might have used the FullText Query Syntax which was quite handy and very comprehensive since it looked like SQL. Unfortunately, this is not part of the 2013 bits anymore so you have to convert all your components so that they use either KQL (Keyword Query Language – Default), either FQL (Fast Query Language).
The Search Engine has evolved a lot positively so other things to consider are :
- If you created Managed Properties via Features/PowerShell scripts…They will still work but the 2013 engine is much better from that perspective so you might want to use the Site Collection Managed properties rather than Farm/Cross-Farm level properties, especially if you defined those for a specific application
- If you defined Search Scopes via Feature Receivers/PowerShell, just forget about them in 2013 and don’t trust readings that tell it still works in 2013! I just doesn’t (the best you can achieve is to have frozen scopes that do not refresh anymore) so you might directly consider converting them to Result Sources
8).asmx based queries
Although they still work, they are deprecated and you’d better get rid of components that consume plain old .asmx web services. The reason why I suggest you to do it is also because they generate some bandwidth overhead and extra complexity. They are just too old. I already avoided them completely in 2010 and was already using both CSOM and REST. Now that these two have been greatly extended, there is really no more excuse to keep working with the .asmx.As a side note, FRPC is also deprecated in 2013 but contrarily to .asmx services, FRPC is a very FAST and lightweight API. The funniest here is that despites of the fact that they are deprecated, it remains the MOST consumed API by Office clients. You don’t believe me? Just open Fiddler and monitor the trafic between SharePoint Designer & SharePoint : almost only FRPC :). So, if you have components that are based on this API, you might consider using REST/CSOM now but for massive operations, I’d still use FRPC. A while back, I wrote a SharePoint cmdlet that was uploadiing all the profile pictures in a very specific scenario (see here for more info http://www.silver-it.com/node/114 ) and if I was facing a similar situation in 2013, I’d still use FRPC.
What? WebParts! I must be kidding right? How come could webparts be a problem to migrate? Well, indeed, you’re unlikely to have troubles with WebParts unless your predecessors were very very cautious and were using CAS policies…and most of the times, CAS policies were used with WebParts of course. If you see that, it will just be ignored in 2013 so it’s not a big deal but maybe the guys who did it had some good reasons for doing it or were explicitely requested to do it by the customer. In that case, you might consider migrating those WebParts to App Parts that won’t be able to run any server-side code.
Also, don’t forget that SandBoxed Solutions are deprecated now, at least SandBoxed Solutions with code behind. SandBoxes that only deploy SharePoint components (lists, fields etc…) to the Host Web *should*¨still be available for a longer term. So, if you have SandBoxed with code-behind, you’d better keep an eye on that and consider alternatives.
This link provides a list of deprecated features in SharePoint 2013.