How to Manage Your Broken Links Post-Migration

Introduction:

If you have already embarked on your migration journey, you must have realized that there are several blockers in user experience post-migration. A major hurdle that impacts the users is the unavailability of bookmarks and embedded links from their old repository.

It’s the same experience irrespective of whether you are migrating from Jive, Slack, SharePoint, or Google Drive to SharePoint Online or any other Microsoft 365 objects like Microsoft Teams or Yammer. Your teammates would either have emails, documents, bookmarks, and Post-its with URLs of the old source site or links within the document referring to a specific issue or task or probably referring to another document that they are struggling to locate after the migration.

How to make the old links work when you are in a new cloud environment?

The old links do work without any changes post-migration. And it is a simple and hassle-free process to get them to work. Create a new URL redirection server with a URL rewrite module and point your DNS to this server. Now this server will take all the requests (which are supposed to go to your old source server), and then redirects the requests for an item already transferred to its new location in SharePoint or Microsoft 365.

Will this URL redirection server work for all source servers?

This will work if you are migrating from an on-premises source server to the cloud. But if your source is cloud, you cannot redirect the old source links to the redirection server. But there is a workaround which we will see in detail in the latter part of the blog.

How to redirect links from old on-premises source server to cloud environment?

There are several ways to redirect links from old on-premises source server to cloud environment. Let’s take an example of SharePoint on-premise to SharePoint online migration. Here, we can either use a separate redirection server, or SharePoint web front-end servers, which is followed by loading the map of source and target links. Here you can use wildcard mapping or direct one-to-one mapping. Wildcard mapping is used if the entire site or library or a specific folder is being transferred to a new SharePoint online site or library or folder. It’s not required to create a one-to-one entry for each document. One-to-one mapping is useful only when you have an important individual link that is migrating to a separate site.

The next example is Jive to SharePoint migration. Collaborative documents in Jive have embedded links of documents, events, videos, or picture libraries. Sometimes the preamble of the files also mentions important links to other documents. In such a case, two approaches can be used. The first one is modifying the link while transferring, which helps the users to rearrange the documents in different libraries or folders without breaking the links. The second approach is the URL redirection server, which redirects the old link into its new location (same as we discussed earlier).

How to redirect links from an old cloud server to the new cloud environment?

Here a different approach must be taken by creating a full map of the old source URL and their new cloud URL. A SharePoint page user can type the old URL and get Microsoft 365 URL easily. Here is an example of Google Drive to Microsoft 365 post-migration, this is the same for any other cloud-to-cloud migration.

Post-migration to the cloud – Redirection

There are many tools for migrating from source content to cloud, but in a post-migration scenario, the most important part is continuing the work seamlessly in a new environment. Users should not struggle to find their old documents or bookmark links. An environment should be created where either the links work automatically or they can be found easily. We hope this blog has helped you learn how you can manage your broken links after a migration has been executed.