The Process of SharePoint 2010 to 2013 Migration |
Posted: May 23, 2018 |
The Process of SharePoint 2010 to 2013 Migration In the process of SharePoint 2010 to 2013 migration, you utilize the database-attach strategy to migrate. In the database-attach technique, you initially make and configure a SharePoint 2013 farm. At that point, you duplicate the content and service application databases from the SharePoint 2010 Products farm, and after that connect and migrate the databases. This upgrades the information to the new form. Site owners would then be able to migrate individual site collections.
This article helps you comprehend the upgrade sequence with the goal that you can design a redesign venture. To get nitty gritty strides for an overhaul, see Upgrade content databases from SharePoint 2010 to SharePoint 2013 and Upgrade a site gathering to SharePoint 2013. The main stage in the upgrade process makes the new SharePoint 2013 farm: 1. A server farm manager installs SharePoint 2013 to another farm. The admin configures farm settings and tests. 2. A server farm admin sets the SharePoint 2010 Products farm to read-only with the goal that users can keep on accessing the old farm while migration is in progress on the new farm. Copy the SharePoint 2010 Products databases The second stage in the update procedure duplicates the databases to the new environment. You utilize SQL Server Management Studio for these tasks. 1. With the farm and databases in read-only mode, a server farm admin moves down the content and administration application databases from the SQL Server example on the SharePoint 2010 Products farm. 2. The server farm admin reestablishes a copy of the databases to the SQL Server instance on the SharePoint 2013 farm and sets the databases to read-write on the new farm. Upgrade SharePoint 2010 Products databases and service applications The third stage in the migration procedure updates the databases and service applications. 1. A server farm admin arranges the administration applications for the new farm. The following service applications have databases that you can upgrade amid this process: • SharePoint Server 2010 and SharePoint Foundation 2010 • Business Data Connectivity service application • SharePoint Server 2010 only • Managed Metadata service application • PerformancePoint Services application • Inquiry service application • Secure Store Service application • User Profile service application 2. A server farm admin makes a web application on the SharePoint 2013 farm for each web application on the SharePoint 2010 Products farm. 3. A server farm admin installs all server-side customizations. 4. A server farm admin then joins the content databases to the new farm and upgrades the content databases for those web applications. 5. A server farm administrator confirms that the upgrade is successful. Upgrade SharePoint 2010 Products site collections The final stage in the upgrade procedure is to redesign the site collections. In SharePoint 2013, site owners are responsible for updating their sites. The update procedure for My Sites is somewhat not quite the same as for different kinds of site collections. Update My Sites A server farm admin redesigns the My Site host and afterward individual users can upgrade their My Sites or the farm admin can update them by utilizing PowerShell. The following outline demonstrates four phases for the My Site host and My Sites amid the upgrade process. 1. The My Site have has not been redesigned. My Sites can't be updated yet. 2. A server farm manager has updated the My Site have. No MySites have been updated. 3. A few clients have updated their My Sites. 4. Every one of My Sites has been updated. Upgrade SharePoint 2010 2013 Products site collections Owners of all other site collections can begin to upgrade their sites when they see a warning on their site's landing page that the new version is available. The following demonstrates four phases for a site collection amid the migration process. Stages in upgrading site collections 1. The site owner runs the site collection wellbeing checks to decide status for an upgrade. The site owner finds out the to issues before they proceed with the subsequent step. 2. Alternatively, the site proprietor asks for a migration evaluation site collection. A timer job rushes to make the site collection and the site owner gets an email message when the evaluation site collection is prepared. The site owner reviews the new UI. Following a few days or weeks, the evaluation site collection lapses and is erased by a timer job. A server farm admin can decide the time allotment before expiration. 3. At the point when the site owner is prepared, the site owner begins the upgrade procedure. The site collection wellbeing checks are run again automatically. The site proprietor must address issues before migrating. Suppose that wellbeing checks returns no issues, the migration begins. 4. At the point when the upgrade is finished, the site owner sees the Upgrade Status page that contains the status and a link to the update logs. The site owner audits the site to ensure that everything works correctly.
|
||||||||||||||||||||||||||||||||||||||||||
|