Migrate site customizations from SharePoint 2010 to 2013

Some readers will have learned the hard way when migrating from SP2007 to SP2010: custom code and site customizations in general are not to be overlooked in your SharePoint migration planning. In this article, we will look at a few things to keep in mind with site customizations when considering a move to the next version. A future article will provide an overview of migrating custom code and server-side solutions.

Branding and UI Customizations will need rework after the migration

I know, it’s a harsh way to start this article. The user interface is one of the things that has most obviously changed between SharePoint 2010 and SharePoint 2013. There is the new Modern look, and the visuals have received a much needed makeover. Under the hood, the changes are also very thorough with new features like Minimal Download Strategy, HTML5, Micro Templating and the Design Manager that not only change the way users interact with SharePoint, but also the way SharePoint prepares and serves pages to users.

The bright side is that SP2013 makes it much easier to apply new branding independently of where it applies. It’s also more in line with modern tools, and it requires much less arcane knowledge of SharePoint’s inner workings so your web designer will be able to play a greater role.

Many SharePoint Designer customizations will not migrate successfully to SharePoint 2013

SharePoint Designer

When SharePoint was still new and innocent, many people jumped on the SharePoint Designer bandwagon. Directly modifying the look of each site pages was easy, quick, and secure (it only affects this page). Often, it was the only known way to implement some much wanted changes.

Whereas in SP2010 you were editing ASP.NET pages and XSL item styles and list view web parts, SP2013 is going in a radically different route for customizations, one that is even more mainstream: HTML, CSS and JavaScript.

If your site owners have been freely using SharePoint Designer, be prepared for a complete do over of their sites (and you should also review your governance, but that’s another topic).

Special mention: Content Editor WebParts

The Content Editor WebPart has long been touted as the holy grail of no-code customization. If you have been using it to insert HTML elements, they should migrate properly (but will most certainly clash with the new look). If you have been promoting the use of off-the-net JavaScript snippets, most of them will fail as their target is likely gone or at least changed. Know also that SP2013 has a new Script Editor WebPart, specifically for entering HTML and JavaScript snippets

You can run SharePoint 2010 inside of 2013 to ease the migration

This is the good news. And I mean as-is. Not like SP2007 running in SP2010 under a false visual.

  • SharePoint 2013 offers the option to natively run legacy solutions on the actual pages and binaries from SP2010.
  • You can also ask SharePoint 2013 to clone your 2010 site to a new location so you can test it and log discrepancies.

Those two features will buy you some time while you prioritize the UI upgrades, but beware : users will not see any of the new 2013 features while you run their site in 2010 mode. You can't eat your cake and have it too.

If you want to learn more, see the SharePoint 2013 Supported Migration Scenarios where we cover more about it.

Future-proof SharePoint 2010 customizations for an eventual upgrade

Good preparation is half the battle. You should aim for an up-to-date list of current customizations and evaluate their usefulness, then regroup similar ones into something more robust and generic. Customizations that change the behaviour of the interface itself will generally not migrate well. If you have doubts about migrating specific modules, feel free to send me a description or screenshot and I will gladly give you my best estimates for it. Microsoft has published on TechNet a treasure trove on information and guides for migration planning and execution.

There are many proven software development practices that can help produce solutions that will better stand the test of time. One of the best protections against change is the adoption of best practices and strong governance.

We have always enforced a strict no-customization policy, so we're safe?

Mostly, yes. But with SP2013 you might want to read on and reconsider this policy (I know, you probably heard that when SP2010 came). And hopefully you have not given into another common mistake: overly relying on a happy mismatched mix of 3rd party add-ons.

Should I customize my SharePoint 2013 site?

Again, SharePoint 2013 brings massive changes to the UI, and the way it works behind the scenes. One of the key area of improvement was to bring interface design to a wider audience by choosing easier technologies and loosening up on the ecosystem (you can now use tools like Adobe’s Dreamweaver to edit SharePoint branding. Or even Notepad).

Customizations can now also be at the same time much more powerful, and much more generic and reusable. On top of that, the new App model gives you the opportunity to create your own custom modules, and with a few lines hook it to the branding and services provided by the server, without deploying anything potentially harmful on the server. So your customizations live more independently of the platform, now this will definitely ease future migration efforts!

Should you design your own site customizations with SP2013? Though question. I expect that things will be a bit chaotic at first as everyone attempts to understand and master the new possibilities. Then trends will emerge, and we learn from our mistakes, as always. It might pay off to sit back with an non-customized farm for a while.

The best bet is always to keep a good inventory of that you have on your farm, and always take the opportunity to do a good pruning and cleaning when you undertake your SharePoint migration. This will reduce complexity and cost of your farm.

    You might also like