In this post we will look at how the image tags managed metadata column creates issues for ShareGate migrations and how to resolve them.
Intro
Image tags were introduced in July 2021 and are automatically added by Microsoft AI to improve search. When images get uploaded into document libraries, SharePoint will analyse them upon upload and tag them based on a set of 37 basic tags. SharePoint will also re-analyse each time an image is updated and update the image tags.
The image tags column is a managed metadata column that isn’t immediately available within a document library. you have to upload an image first, before the image tag column appears – which can take several hours.
The problem
When migrating files at scale using migration tools such as ShareGate desktop, you will start to see errors in your migration reports related to the image tags column. In the example below, the details of each failed item showed the same or similar errors:
“Property Image Tags: The following values are unavailable: ‘outdoor, sign, text’. Please specify another value.”
ShareGate migration errors
Example migration report showing the image tag error messages.
The solution
The way I resolved this issue was to change an option within the migration task itself to ignore the image tag column managed metadata values. To do this I did the following in ShareGate:
In ShareGate desktop > start a copy content migration
Select your source and destination sites
In the copy content screen > select Options
Select Metadata > then expand Document
You will see the image tags column here > change set mapped value to ignore
Tick apply for all version history
Set your copy content migration task to ignore the image tasks column metadata.
In this post we look at three different ways you can copy a page from one SharePoint site to another.
Intro
The copy/ move features within SharePoint Online were introduced a few years ago, and although they are pretty good, aren’t without their limitations – something I wrote about in 2021. One such limitation is the inability to be able to copy or move site pages from one SharePoint site to another – a frequent request of users and of the SharePoint community to Microsoft, but so far nothing has been implemented.
I’m going to cover a few ways you can copy a site page from site to site, using a variety of different tools and products along the way.
#1 Create a flow in Power Automate
In this example we can use Power Automate to allow users to select the page they want to copy, input the site URL they want to copy to and let the flow do its magic!
Create a new flow in Power Automate > use the instant cloud flow option.
Create a for a selected file trigger > enter the site address and library name.
NOTE: In my example, just entering ‘Site Pages’ resulting in my flow not appearing in the Site Pages library. This seems to be an issue with the for a selected file trigger. In order to get it to show up, I had to use the library ID instead of the library name. To get the library ID:
Open the library settings > more library settings
Copy everything between List=&7B until %7D – this is the library ID
Copy the library ID which is the numbers between &7B and %7D
In the for a selected file trigger > add an input
Select text as the user input type > update the input name and input value placeholder text. This user input type will be used to allow users to enter the site URL they wish to copy their pages to.
Add a text user input type to allow users to input the destination site URL.
Add a get file properties action and configure with the following:
Enter the source site address of your site pages library
Enter either site pages, or the ID of your site pages library
Under ID > select ID from the for a selected file trigger
Add a copy file action and configure with the following:
Current site address: source site address of your site pages library
File to copy: Identifier from get file properties
Destination site address: destination site (or whatever you called your user input) from for a selected file
Destination folder: /SitePages
If another file is already there: copy with a new name (optional)
Three steps – that’s it! Now go ahead and test your flow by selecting a site page and copying it to a different site by running your flow.
#2 Use PnP PowerShell
Another way you are able to do this is with PowerShell, in this case I’ll defer to the brilliant SharePoint diary who has a great write up, including all cmdlets you need to copy a page from site to site, or copy all pages. I’ll include the relevant sample for my blog post, but full credit goes to SharePoint diary:
#Parameters
$SourceSiteURL = "https://crescent.sharepoint.com/sites/marketing"
$DestinationSiteURL = "https://crescent.sharepoint.com/sites/branding"
$PageName = "About.aspx"
#Connect to Source Site
Connect-PnPOnline -Url $SourceSiteURL -Interactive
#Export the Source page
$TempFile = [System.IO.Path]::GetTempFileName()
Export-PnPPage -Force -Identity $PageName -Out $TempFile
#Import the page to the destination site
Connect-PnPOnline -Url $DestinationSiteURL -Interactive
Invoke-PnPSiteTemplate -Path $TempFile
The final option we have available to us is to utilize 3rd party migration tools to migrate pages between sites. For this example I’ll be using ShareGate, but there are other migration tools that are able to do the same thing:
Open ShareGate desktop > press copy.
Select copy content only.
Enter the URL of your source site > select the Site Pages library.
Do the same for the destination site.
Select the page from the source location you wish to copy
Under options, make the following configuration changes:
Check preserve authors and time stamps
Check permissions
Uncheck user alerts
Check web parts
Check version history
Uncheck flatten folder hierarchy
Check update links
Check check in as = published
Press start copy. Once completed, you should see two successful migration task items for your copied page:
Now you will find your newly copied page in the destination Site Pages library. In my experience of copying pages using ShareGate, images hosted within a CDN will still be present within your page, as will all the of text, layouts and any formatting. Images that are stored within different sites may error, as will document library/ list web parts that point to different sites also.
I’ve been suitably inspired by Andrew Warland’s fantastic two-part series documenting his approach and migration to SharePoint Online, so much so that I thought it would be a fun series to write about my own experiences.
It is’nt my intention to necessarily document Microsoft best practice in this series, rather just to explore some of the challenges, sucesses and experiences I notice along the way.
The current situation
My organisation has recently made the decision to move to to the cloud, with O365 being the naturally preferred destination. SharePoint has been well embedded, and heavily used within the business for several years, with on-premises SharePoint 2010 currently in production.
Finally, in terms of the SharePoint architecture and data volume, there are only three web applications to merge together as part of the migration effort. However, there are several site collections within our main intranet web app, plus many sub-sites nested within them, meaning the huge database sizes behind these site collections could prove difficult come migration time.
A note on the new, flat structure
Our current environment has a well established top-down structure in place that is generally consitent across the environment.
Having already made the investment in ShareGate, this will be the tool of choice for the migration. In the version 11.0 release of ShareGate, a new restructure option now allows you to promote sub-sites to top-level sites post inital migration from the source SharePoint environment.
The new restructure option in ShareGate 11.0
Considerations for a successful migration plan
One of the biggest issues to be resolved before we can start any sort of migration activity, is the fact that we have several content databases well over the 200GB recommended general use size limit.
Microsoft best practice suggests that any environment that has site collections, sites, content databases, libraries or lists that exceed the software boundaries and limits should be remediated prior to any migration activity. In this case, the main idea is to split each content database that exceeds 200GB into seperate content db’s, and where neccessary, move or promote sub-sites to site collections and attach new db’s.
Armed with the knowledge of the recent restrcuture functionality coming to ShareGate, plus my own personal feeling that any remediation activities to our current environment may in of itself carry adverse risk to the estate we proposed a different approach.
With all the reporting capabilities at our disposal via ShareGate, I was able to get a firm grasp of what resides within each site collection in our environment, in terms of:
The size of each sub-site underneath the top-level
Number/ size of libraries and lists
Number of items in each of the above
Any workflows running in any of the above
From this I ran a trial migration of a sub-site from SharePoint 2010 to a newly created team site in SharePoint Online.
Pre-migration
Before I kicked off the migration, I ran the source analysis tool within the Migration > Plan section of ShareGate. I noted the following obersavations:
The source analysis within “migration” in the ShareGate tool, although listed as only being able to analyze up to SharePoint 2013, does in-fact work for 2010
ShareGate source analysis
The source analysis cannot run at the sub-site level, meaning that you need to run it at the site collection level then just filter down to the sub-site in question through the report itself
Source analysis gives you a report of all checked-out files within a source site.From this, I created a simple view within each of the libraries that contained checked-out files to send to the site owners for action
Post-trial migration
The trial migration completed successfully as expected, however there were several interesting results I noted:
1. Everyone receieves a welcome email
If you migrate the permissions, once the source permission groups migrate each user will recieve a welcome email to the new SharePoint Online site.
Publishing sites seem to be the trickiest to migrate, especially those with custom master pages or page layouts. When migrating publishing sites, the Pages library is migrated wholesail, meaning the content won’t reside in the SitePages library (where new client-side pages are located).
3. Un-editable modern homepage
After the migration had completed, the new team site homepage threw up an error every time you tried to edit it.
I tried some of the documented resolution steps found here, but none of them worked for me. My solution was to just create a new page to replace the broken homepage, add all the relevant webparts and make this one the new default homepage.
Transforming classic publishing site pages to client-side pages
Publishing site pages will all be migrated as classic SharePoint pages, without the modern look and feel of a client-side page. My understanding is that for publishing pages with custom page layouts, additional metadata or custom content types will need to be transformed via PowerShell and creating a custom mapping file.
(I’m planning on writing a seperate blog post walking through an advanced publishing page transformation in the near future)
Its also worth considering that in the release notes for ShareGate 11.0 it makes mention of the fact they are researching the ability to transform classic to modern pages, so that could well simplify this process in a future release.
Conclusion
Overall, I was happy with our trial migration and believe it is a viable approach for us to move from on-prem to O365. Some lessons learned for myself would be to consider and SharePoint permissions audit prior to migration to remove any unecessary permissions, send an inventory out to site owners aswell as checked-out files, all in the name of reducing the migration effort.
This will be an ongoing series of posts, which i’ll focus more the on the nitty-gritty of the migration effort than anything else, but as always if there is any feedback or suggestions on how to improve this site, please let me know!
SharePoint Stuff 