I have just finished manual migration SharePoint on-prem to SharePoint Online.
And this post is about:
- Why I chose manual migration?
- How is it done?
Just to make sure that you are aware of Supported Migration scenarios, let me post this link for you - Migrate to Office 365 – Supported Migration Scenarios. This blog is obviously to support 3d party tool for migration, in this case - Sharegate. I am not related to this product in any ways, moreover I have never used it. But I like how the author presents the information regarding SPOnline migration simply and clear.
So, Why I chose manual migration?
I took some time to analyze leaders in 3rd part tools for SharePoint Migration , and came up with impression that it's worth the money if content is bigger than 50 Gb. In my case, it wasn't.
So, I have decided to do a manual migration.
NOTE: MANUAL MIGRATION WILL REPLACE CREATED BY|MODIFIED BY as well as CREATED DATE|MODIFIED DATE with the user who is doing migration and date will be set as current date when migration is done.
In case you have to preserve these metadata, you need to to use 3rd party migration tools.
How is manual migration done?
You have several options here, depending what you want to copy over.
The fastest and easiest way is:
1. Save site as a site template.
This way you can copy the entire site with content (if you set the option "Include content").
You can't save site template if:
- In the site Publishing feature is activated;
- If list is to large to save as a template (The size of a template cannot exceed 52428800 bytes.)
- Sometimes lookup, managed metadata columns prevent from saving the site as a site template.
2. Save list as a list template
In case site template wont' work out. You can create a blank site in SharePoint Online, and than transfer content list by list.
The easy way to transfer list - is via List template with content. (List- Settings -> save as a template)
This way you can save list as well as library.
You can't save list template if:
- The list is too large to save as a template. The size of a template cannot exceed 52428800 bytes.
- The list has a lookup or metadata columns
Special case: How to save Wiki as a list template:
There is no option "save as a template" under Wiki library settings. BUT, you can save Wiki as a template.
You can do that via SharePoint designer. Open the site in SharePoint Designer, select wiki library and in the panel above you will find the option "save as a template"
3. Copy data via Access
In some cases, you have to use Access to bring the data over into the cloud. You can find "Open with Access" in the list menu.
You have 2 options how you can link data in the Access:
- Link to data;
- Export.
How to choose over another?
You don't need to write back to source (on-prem), plus sometimes you want to transfer managed metadata, user, lookup columns. This is a perfect candidate for Export.
The export will convert managed metadata, user, lookup into text fields.
In contrary, most of the time, for destination, "Link to data" brings the best result.
How to migrate lookup, user, managed metadata columns?
Before migrating list with the lookup, you have to create a list for the lookup value in the destination site.
Then you can create a destination list with the lookup and link the list to Access. Meanwhile you copy data of the source list to Acces, the lookup values are converted to text value.
Then copy data from the source table to the destination table.
After the data are copied over via Access, update the lookup column in Quick Edit mode in the list
Here are the cases when I use Access:
- Copy Links list;
- Export from the source a list with a user column.
- Export from the source a list with a lookup.
- Export from the source a list with a managed metadata column.
4. Copy files via Explorer
Access allows you to copy list over to the cloud. But you can't use it for Libraries.
To copy files, use "Open with Explorer"
Exception: Files large than 50 Mb while copying give error "The file size exceeds the limit allowed and cannot be saved"
You still can copy these files by dragging and dropping directly in the document library:
Special bonus: How to set read-only on list?
And this tip is kind of obvious, but I want to share it anyway to complete the picture of manual migration.
Once you have transferred the data from the source, you want to make sure that the source data will not be changed. The manual migration is tedious, so you want to limit incremental update as much as possible.
First of course, you want to make sure that you start with the data that are not updated frequently. This way the chances that anybody noticed that the list\site is read-only are really low.
To set the list\libraries\site read-only, break the permission inheritance and change the permission to "Read"
Summary:
The described manual migration steps are exactly what I did to migrate the portal.
Please note, that if you have customization, you need to figure out whether you want to leave it behind, if no, would be possible to convert it to the sandbox solution?
In my case, I have got rid of all customization before the actual migration back in the migration from SP2010 to SP2013 on-prem. This way I have prepared the farm in advance.
To migrate 4 Gb of the content of 16 subsites (1 site collection, with no user site collection content migration) took 80 hours - 2 weeks of solo work.
Welcome to the cloud! Once you have done it, find a new job)
And this post is about:
- Why I chose manual migration?
- How is it done?
Just to make sure that you are aware of Supported Migration scenarios, let me post this link for you - Migrate to Office 365 – Supported Migration Scenarios. This blog is obviously to support 3d party tool for migration, in this case - Sharegate. I am not related to this product in any ways, moreover I have never used it. But I like how the author presents the information regarding SPOnline migration simply and clear.
So, Why I chose manual migration?
I took some time to analyze leaders in 3rd part tools for SharePoint Migration , and came up with impression that it's worth the money if content is bigger than 50 Gb. In my case, it wasn't.
So, I have decided to do a manual migration.
NOTE: MANUAL MIGRATION WILL REPLACE CREATED BY|MODIFIED BY as well as CREATED DATE|MODIFIED DATE with the user who is doing migration and date will be set as current date when migration is done.
In case you have to preserve these metadata, you need to to use 3rd party migration tools.
How is manual migration done?
You have several options here, depending what you want to copy over.
The fastest and easiest way is:
1. Save site as a site template.
You can't save site template if:
- In the site Publishing feature is activated;
- If list is to large to save as a template (The size of a template cannot exceed 52428800 bytes.)
- Sometimes lookup, managed metadata columns prevent from saving the site as a site template.
2. Save list as a list template
In case site template wont' work out. You can create a blank site in SharePoint Online, and than transfer content list by list.
The easy way to transfer list - is via List template with content. (List- Settings -> save as a template)
This way you can save list as well as library.
You can't save list template if:
- The list is too large to save as a template. The size of a template cannot exceed 52428800 bytes.
- The list has a lookup or metadata columns
Special case: How to save Wiki as a list template:
There is no option "save as a template" under Wiki library settings. BUT, you can save Wiki as a template.
You can do that via SharePoint designer. Open the site in SharePoint Designer, select wiki library and in the panel above you will find the option "save as a template"
3. Copy data via Access
In some cases, you have to use Access to bring the data over into the cloud. You can find "Open with Access" in the list menu.
You have 2 options how you can link data in the Access:
- Link to data;
- Export.
How to choose over another?
You don't need to write back to source (on-prem), plus sometimes you want to transfer managed metadata, user, lookup columns. This is a perfect candidate for Export.
The export will convert managed metadata, user, lookup into text fields.
In contrary, most of the time, for destination, "Link to data" brings the best result.
How to migrate lookup, user, managed metadata columns?
Before migrating list with the lookup, you have to create a list for the lookup value in the destination site.
Then you can create a destination list with the lookup and link the list to Access. Meanwhile you copy data of the source list to Acces, the lookup values are converted to text value.
Then copy data from the source table to the destination table.
After the data are copied over via Access, update the lookup column in Quick Edit mode in the list
Quick edit allows you update manually Managed Metadata and User columns pretty fast.
Here are the cases when I use Access:
- Copy Links list;
- Export from the source a list with a user column.
- Export from the source a list with a lookup.
- Export from the source a list with a managed metadata column.
4. Copy files via Explorer
Access allows you to copy list over to the cloud. But you can't use it for Libraries.
To copy files, use "Open with Explorer"
Exception: Files large than 50 Mb while copying give error "The file size exceeds the limit allowed and cannot be saved"
You still can copy these files by dragging and dropping directly in the document library:
Special bonus: How to set read-only on list?
And this tip is kind of obvious, but I want to share it anyway to complete the picture of manual migration.
First of course, you want to make sure that you start with the data that are not updated frequently. This way the chances that anybody noticed that the list\site is read-only are really low.
To set the list\libraries\site read-only, break the permission inheritance and change the permission to "Read"
Summary:
The described manual migration steps are exactly what I did to migrate the portal.
Please note, that if you have customization, you need to figure out whether you want to leave it behind, if no, would be possible to convert it to the sandbox solution?
In my case, I have got rid of all customization before the actual migration back in the migration from SP2010 to SP2013 on-prem. This way I have prepared the farm in advance.
To migrate 4 Gb of the content of 16 subsites (1 site collection, with no user site collection content migration) took 80 hours - 2 weeks of solo work.
Welcome to the cloud! Once you have done it, find a new job)
No comments:
Post a Comment