On Demand Migration for SharePoint - Term Store Migration - New Feature Spotlight

Quest is excited to announce the release of a new feature, which takes On Demand Migration another step towards parity with other SharePoint migrations within Quests portfolio. We are constantly working on releasing new features and modules to allow customers to perform complex migrations of their M365 tenants via Quest On Demand and removing the need to install further solutions manually and locally on to physical (or virtual) servers and desktops.

In this article, the spotlight will be on the migration of global and site level term stores.

Info: The feature highlighted in this article has been released in November 2022. However, it is currently placed behind a feature flag. Quest will be gathering feedback from customers and partners alike, who will be testing this feature in production migrations. Should you require to utilize this feature for your migration, please contact Quest Support with the following information:

  • Quest On Demand Organization ID
  • Quest On Demand Deployment Region
  • Name of the Feature Flag to be enabled. In this case migration.sharepoint.termstore.add

Where can I find this new feature?

Once the feature flag has been enabled, you will be able to find a new tile displayed on the dashboard within the SharePoint migration module titled “Global Term Store”, as shown in the screenshot below.

This tile will display the current migration state and information on when this task was last run – this includes the discovery of the global term store on the source.

How do I migrate the term store?

From the same dashboard from where the Global Term Store tile is displayed you will find a new option in the above displayed tab called “Migrate Term Store”.
This option will take you directly to the configuration of the “Migrate Term Store”-task with the option to schedule this task to run now or at a later point in time. Once the task is scheduled to start, the task will be updated with its appropriate events informing the migration user of what is being migrated, if there have been any warnings or failures and if the migration has been successful.

The status of the global term store migration tile will also be updated and displayed on the dashboard.

It is important to note that these steps need to be followed for the migration of the global term store.
The migration of site level terms will be automatically migrated as part of the migration of SharePoint Sites under the “SharePoint Contents”-tab.

What do the results look like (admin and enduser experience)?

Each unique identifier for migrated term groups, term sets and terms are maintained and the same between source and target tenants. Any webparts, (work-)flows, apps and customizations utilizing the IDs on the source will remain intact post-migration. This can be confirmed by checking the SharePoint admin portal in your M365 tenant under “Content Services” > “Term Store”.

For migrated SharePoint sites where terms are in use i.e. in SharePoint lists and libraries, the migration will ensure that the terms are still properly set and referenced with the migration of the list.

Further Information

For more detailed information on this and many other features within On Demand Migration for SharePoint, check out the On Demand Migration User Guide or visit us at Quest.com for more information.

Parents
  • The feature sounds super! Is there already a small documentation for the migration that describes, among other things, the necessary permissions in the tenants?

  • Hi Florian, thanks for the feedback and your question. Since you connect your tenant with On Demand using the tenant administrator (a user account with the Global Administrator security role) and grant Azure consents and permissions to the On Demand Migration service prinicipals there is no further requirement for specific permissions to be manually granted or entered. During the migration the app@sharepoint account will be added as Term Store Administrator for the duration of the migration and once completed, the account will automatically be removed again.

    We currently have a case open where the app@sharepoint account cannot be resolved in a customers tenant, which we are currently investigating. Let us know should you run into this (or any other problem) when you test this feature in your tenant(s).

    Full documentation of this feature will be added to the On Demand Migration User Guide once we release this feature fully and it is no longer an optional setting behind a Feature Flag.

    Let me know if you require further information or assistance. Feedback is  also always welcome!

  • Hi Gary,
    thanks for your feedback! We have exactly the same problem with the account.

    Here is the message from the quest console:

    The required term store admin privileges are not set. Confirm that "app@sharepoint" user is a term store admin on both source and target.

  • Hi Florian,

    thanks for letting us know! This is exactly the reason we released the term store migration behind a feature flag and have not gone GA yet, so we can find such bugs and provide fixes before full release.

    We are currently investigating this issue and have found a potential workaround on the microsoft forums where it is suggested to use PnP to resolve the user and trying to resolve using i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint - however, we also found that this workaround doesn't work for everybody. You can find more information on this here: https://techcommunity.microsoft.com/t5/sharepoint-developer/the-app-sharepoint-principal-is-not-resolving-in-newly-created/m-p/1595624

    It would be great if you could email me directly with furhter information about your On Demand Organisation and project in which you are testing this feature @ gary.hughes@quest.com - you can copy all details directly from the UI within ODMSP by going to your migration task for the term store migration under "Tasks" and then select "copy diagnostics".

Reply
  • Hi Florian,

    thanks for letting us know! This is exactly the reason we released the term store migration behind a feature flag and have not gone GA yet, so we can find such bugs and provide fixes before full release.

    We are currently investigating this issue and have found a potential workaround on the microsoft forums where it is suggested to use PnP to resolve the user and trying to resolve using i:0i.t|00000003-0000-0ff1-ce00-000000000000|app@sharepoint - however, we also found that this workaround doesn't work for everybody. You can find more information on this here: https://techcommunity.microsoft.com/t5/sharepoint-developer/the-app-sharepoint-principal-is-not-resolving-in-newly-created/m-p/1595624

    It would be great if you could email me directly with furhter information about your On Demand Organisation and project in which you are testing this feature @ gary.hughes@quest.com - you can copy all details directly from the UI within ODMSP by going to your migration task for the term store migration under "Tasks" and then select "copy diagnostics".

Children