Portal migration from SharePoint 2010 to SharePoint 2013. What has changed and how to live with it

In this topic, we share our real experience in the migration of portals from 2010 to 2013 SharePoint. The issue has been resolved long ago, it is necessary to migrate, and for sure the management has already set deadlines when this should be done. This is where our material may be useful for understanding how to approach this matter. In order not to make a huge article with a bunch of specific inserts of technical information, we focused on the main thing - on differences in migration from 2007 to 2010 with migration 2010 to 2013 and at the main stages.

If you are faced with an even more difficult task to migrate 2007 to 2010, and then to 2013, read our last year’s material , where we already talked about the migration of the SharePoint 2007 portal to SharePoint 2010.

As always, we tell in practice, let's start with the task before us:

Before us is an internal corporate portal:

• Intranet - an old information portal with specialized functionality and design, developed by Company 1, is currently being used by several company divisions;
• Intraru2 is a new information portal with specialized functionality and design developed by Company 2. Also, modules developed by us for booking meeting rooms are involved in the portal. Currently used by most divisions of the company;
• Docflow - a portal with specialized functionality and design, developed by Company 3, is used for the workflow by the legal department;
• HelpdeskCo - a portal with standard functionality, used by the IT department;
• KnowledgeBase is a portal with standard functionality used by the IT department.

Complementing the picture with the final touches: there are more than 15 different Solutions installed on the SharePoint farm, more than 50 GB of content databases, and various service applications are used in the work of the portals:
')

• profile service
• search service
• webapp application service
• metadata service.

All this farm is used by more than 2.5 thousand users.

Our task was to migrate the Intranet, HelpdeskCo, KnowledgeBase portals and our modules for booking talks from the Intraru2 portal to Sharepoint 2013. Two important points worth mentioning here are:

1. As always, you need to switch the portal version so that almost no one notices.
2. "Company 2" migrated its part of the development itself.
3. "Company 1" and "Company 3" no longer lead customer support, so their decisions were hanging in the air.

Practical advice to those who support and develop portals: buy third-party solutions with source code only and use your administrators by using them - you will be sure that you will not be asked for extra money and that you have exactly what you bought.

As experience shows, when upgrading to the next portal versions, developers request additional money, and they are not always justified.

What has changed in the approach to migration for 2013

Let's look briefly at the changes in the migration process, as well as in the requirements for the farm:
technet.microsoft.com/en-us/library/ee617150 (v = office.15)
technet.microsoft.com/en-us/library/cc262485.aspx
technet.microsoft.com/en-us/library/ff382641.aspx

Farm hardware requirements:

• the farm 2013 web server requires approximately twice as much RAM as the farm 2010 web server (8GB versus 4GB for development and 12GB versus 8GB for minimal use);
• Farm 2013 web server is officially supported on Windows 2008R2SP1 / 2012, but is not yet supported on 2012R2.
• Fast-Search site migration is not supported: you must either delete sites or replace them with “Enterprise Search”;
• The migration of PowerPoint Broadcast sites that come with the Web App is not supported.

You can migrate only some service applications:

• Business Data Connectivity
• Managed metadata
• Performancepoint
• Secure store
• User Profile
• Search Administration.

Rejection of the “Visual Upgrade” function:

1. Now there is no “visual upgrade” function, but the opportunity has appeared to test and migrate individual collections of sites to the 2013 species.
2. Now there is a native mode of operation of 2010 sites, and on the file system, in addition to folder 15, there is also folder 14, while the “\ _layouts \” link goes to the “14 / layouts” directory, and the “\ _layouts \ 15 \” link goes to the directory "15 / layouts".



3. Now it is possible to install WSP solutions from the 2010 farm, and you need to use the “-CompatibilityLevel“ 14,15 ”flag and, as practice has shown, most of the solutions will work.
4. By default, web applications on farm 2013 are created and operate in the “CLAIM” mode of authorization, so that during migration you will need to convert the web application and users to the “CLAIM” mode.

Usually we train (test migration)

So, as usual we analyzed the portal, made a test farm, on which we worked out the first errors. 90% of WSP solutions were installed without problems, others required corrections, the main errors encountered were:

• wrong file paths;
• Solution incompatibility with Framework 4.5.

When checking the database, there were mostly errors “residues from remote solutions”:

• incorrect web parts on pages;
• incorrect "Feature";
• incorrect WSP solutions.

Next, having made sure that these web parts, features and solutions are not used in the work, we cleaned the base, deleted unused site collections, document versions and baskets data.

The result was a clean, error-free database of content, which was connected to the test farm.

During the test migration, service applications were also migrated, which did not cause any difficulties:

• profile service;
• metadata service.

After connecting the databases and converting the web application to the authorization mode, “CLAIM” got a problem with the functionality of our solution for booking meeting rooms, so it was necessary to fix it to work with “CLAIMS”.

As an example of custom-development migration, we present the solution for booking meeting rooms , the correct architecture allowed us to make the edits minimal, namely, to change the configuration for the wcf service in the web.config.

For example, adding the useRequestHeadersForMetadataAddress attribute to the behavior section:

<serviceBehaviors> <behavior name="RoowRequestBehavior"> <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="false" /> </behavior> </serviceBehaviors> 

In addition to the changes to the web.config, fixes touched on how to interact with SharePoint Search Services. If in SharePoint 2010 the interaction occurred through FullTextSqlQuery and resembled a normal SQL query:

 const string querySchema = "SELECT {0},{1} FROM Scope() WHERE (\"scope\"='people') AND (\"{2}\"='{3}'"; ResultTableCollection rtc = null; var ftsq = new FullTextSqlQuery(ServerContext.Current) { QueryText = String.Format(querySchema, employeeIdField, nameField, departmentField, department), ResultTypes = ResultType.RelevantResults }; rtc = ftsq.Execute(); 

Now you need to use KeywordQuery and the same query will look like this:

 const string querySchema = "{0}:{1}"; ResultTableCollection rtc = null; var kwq = new KeywordQuery(site) { QueryText = String.Format(querySchema, departmentField, department), ResultTypes = ResultType.RelevantResults, KeywordInclusion = KeywordInclusion.AllKeywords, HiddenConstraints = "scope:" + "\"People\"" }; kwq.SelectProperties.Add(employeeIdField); kwq.SelectProperties.Add(nameField); SearchExecutor se = new SearchExecutor(); rtc = se.ExecuteQuery(kwq); 

Our advice: before migration, if there are custom components, look at the changes in the API, usually it ends with minor changes in the code.

Next, we had to update the sites to the 2013 view. There were no problems with standard web applications, and the site collections were updated correctly to the 2013 view. Difficulties arose with the web application of the old intranet portal, the check showed multiple notifications:



Accordingly, the next step was a systematic work to adjust the appearance of the portal. I note that not all of the design was successfully transferred to 2013 and there were minor flaws that did not affect the functionality of the portal and, as agreed with the customer, did not correct them any further.

As a result, on the test farm, we worked out possible errors, got a checklist for verification and the order of steps for combat migration.

Battle Migration

As always, after the test migration, we once again did a training run on a clean infrastructure and wrote down in steps how and what to do. Combat migration was performed on a day off so as not to interfere with the daily work of portal users. No new errors occurred during the combat migration, it took about 6 hours.

In the end, I would like to say that the migration process has become a little easier, but you need to remember simple things:

1. Do not litter your portal with unnecessary solutions.
2. Keep the source, settings, all versions of what you install on the portal. Then sometimes it is impossible to figure out where it came from and what will happen if you do not migrate.
3. Describe (document) the configuration of services - search service, profiles, reports, etc. - time passes all is forgotten. As a rule, each setting is important for the performance of the portal.
4. Try not to reinvent the wheel and use the portal functionality as well as possible.
5. Gathered to migrate - do not take the time to practice.

We will be glad if our experience is useful to you. Write questions, if we know the answer, we will definitely advise and help!