Sharepoint Migration Test Cases

With the announcement of latest SharePoint 2019 environment last year, much buzz has been created on how perform on- premises migration from legacy versions to SharePoint 2019. There have been a lot of questions coming up regarding up gradations and SharePoint 2019 migrations like is it possible to upgrade directly from SP 2013 to SharePoint 2019 environment or SharePoint 2010 to SharePoint 2019 environment directly. Microsoft activelysupports documentation for the purpose. In this blog post, we’re going to show you the essentials of SharePoint 2019 on-premises Migration from legacy version.

Select a Path

We are frequently asked for guidance on Testing Plans for SharePoint Site Migrations, so have put together this general guidance. While the complexity and nature of migration projects vary massively, and the implications naturally vary with each use-case, we have compiled this list of tests that are generally worthwhile in most migration scenarios. A big part of the SharePoint Migration Checklist is to ensure the migration schedule is made available to all users. The expected downtime or freeze period needs to be communicated clearly to each site owner well in advance of the migration process.

SharePoint 2019 migration is not that simple from a legacy version. At first, you would have to upgrade to a higher version eventually to 2019 like 2010 to 2013 to 2016 to 2019. However, things get simpler by using a third-party tool like MachPanel Automation tool for SharePoint migration. With MachPanel, the migrations become seamless and hassle free. This is the best migration path form SP 2010/2013/2016 to SharePoint 2019. The experts are at your side to perform the migration steps and provide post-migration support in case you need any guidance after the migration has occurred. For a successful SharePoint 2019 migration you must consider the following:

Plan: it is important to review the source platform (SharePoint 2013/2016) and destination platform (SharePoint 2019). The relevant configurations must be available in the destination platform.

Analysis of unnecessary items: before beginning the SharePoint 2019 migrations, it is a good practice to track down all the unnecessary contents that ate not needed in future. Frequent cleanup is a good practice, anyway

Run Pre-migration tests: it is best of you could run a mock migration, get the results of pre-migration test reviewed and repeat if not satisfied with results.

Create different batches of content for migration: it is beneficial if you classify major Site Collections into batches. Apart from this, you could also classify Sites and Lists, Metadata, Permissions, Content Types etc. for improved migration experience. This certainly avoids many failure points.

Steps

With that said, let’s move on to the major steps and best practices of migrating to SharePoint 2019 on-premise. If you are moving form SharePoint 2013 to SharePoint 2019 environment, you need to know the following steps that highlight the steps involved in a general SharePoint 2019 migration.

1. Upgrade to a temporary SharePoint 2016 farm

2. Upgrade to destination SharePoint 2019 environment

Upgrade to a temporary SharePoint 2016 farm

SharePoint 2013 (final migration only): Select the web application and select the option Remove content database”
Place Database in Read-only mode and create a backup of it.
Now add the content database previously removed by selecting option “Add content database”. This will add DB in read-only mode.
Create a copy and add Database backup file to temporary SP 2016 farm.
Select “Remove content database” to unattached DB from any web application
Restore database and Execute the series of PowerShell commands

ALSO READ
The best use of the Microsoft’s free SharePoint Migration Tool

Upgrade to destination SharePoint 2019 environment

SharePoint 2016: Select the web application and select the option Remove content database”
Place Database in Read-write mode and create a backup of it.
Now add the content database previously removed by selecting option “Add content database”. This will add DB in read-only mode.
Create a copy of Database file form SP 2016 farm and add Database backup file to destination SP 2019 farm.
Select “Remove content database” to unattached DB from any web application
Restore database and execute the series of PowerShell commands as farm administrator.

After a successful SP 2019 migration, the web application is displayed in the latest SharePoint 2019 environment and you are all set to explore the modern experience of SharePoint 2019 environment. For more details about migration, you can check out additional support from Microsoft.

Key points

It is important to highlight a few key points that you should know before you start the migration process.

On-premises Migration will turn out to be half complex if you plan correctly, you can then restructure the content during migration.
Post-migration support is essential: you should keep a check for anomalies once you are in the latest SharePoint 2019 environment.
It is important to note that the intent of migrating to SharePoint 2019 is to aim for better business collaboration and better productivity for business.
Another important aspect is to perform a good cost-benefit analysis on whether the pain of migration is worth it or not.
Know the right Providers: Always make sure the providers provide a post-migration support so that you can turn to your provider if things go out of hand after the migration.

MachPanel Automation tool for Microsoft SharePoint

The aforementioned MachPanel automation tool for Microsoft SharePoint provides complete Orchestration for Hosted SharePoint Service Providers and Enterprises. It supports Multi-tenancy and Segregation for Microsoft SharePoint Server 2019, 2016 & 2013. By making use of this tool, the migration process becomes simple. Apart from this, turnkey solutions are offered for Microsoft SharePoint which improves business productivity by services like design and deployment, planning and migration, reliability and scalability. Management of on-premise SharePoint or sell fully segregated multi-tenant hosted SharePoint 2019 environment (and other environments like SharePoint 2010/2013/2016) isn’t a big deal with MachPanel.

Now you know it, Grab the opportunity for a successful SharePoint 2019 on-premise migration and get your hands on the latest SharePoint 2019 environment and MachPanel.

Migrating existing content into a SharePoint system, and specifically into a SharePoint Page Library -- the foundation of a SharePoint Publishing website -- is neither simple nor straightforward.

Sharepoint Migration Plan

To migrate content into SharePoint we took a look at a number of tools, both commercial tools and custom-built ones paired with a data aggregation framework. Here is a review of our experience, a summary of our final approach and some postmortem thoughts.

Sharepoint Migration Tool Download

Content Migration Scenarios

Scenario 1: Content in a number of locations

In this scenario, the customer had content spread over static sites, an unfamiliar-to-us Web CMS and some custom content databases. All of this content needed to be moved onto the SharePoint 2007 platform.

The core goal was to move all the content to the SharePoint Publishing Portal, into the page library. This required a lot of transformations on the existing content and also required us to pre-check for UTF compliance in addition to stripping of any additional HTML information embedded in it (except links and image URLs).

Scenario 2: Migration from Vignette to SharePoint

This scenario, like the first was to migrate to the SharePoint Publishing Portal from the client's current Vignette content management system. This too created a need to map the various content types in Vignette to SharePoint content types and then perform the migration.

Both scenarios shared the same goals:

Move old content entities to SharePoint Page Libraries
Move old images to SharePoint Picture Libraries and link them correctly in the content entities
Move old documents and other assets to SharePoint Document Libraries and establish the correct links
Move other items like Events, Links, etc.. to corresponding SharePoint Lists
Replication of the site structure inside of SharePoint

Migration Challenges

Vendor Migration Tools

While there are many vendors around who have tools that can migrate items to SharePoint Lists / Document Libraries, there are only couple of vendors who have the tools to migrate content to SharePoint Page Libraries.

This proved to be the first challenge as these vendors are not well advertised or listed on the popular blogs and tool evaluation sites.

Once we found a candidate vendor tool, we moved into the evaluation phase with a sample content migration operation. Our evaluation of the tools showed us the following:

A well defined wizard to crawl websites and map the relevant content blocks to the SharePoint Page Layout fields.
Migration capability of related images and documents to the relevant image / document library and updating of the links.
Limited reporting of the migration process, as it was limited to stopping of the migration process in case of an error.
These tools worked wonderfully when it came to Simple Page Layouts with the standard columns in the page library and started to fail with large number of fields.

During testing we found several problems. For example, we realized that the wizards typically did not allow us to do the content mapping as we needed to. They forced us to map the source content blocks to the target columns based on the Page Layout. This approach did not take into consideration the Page Libraries Content Type columns.

What actually needed to be done was to map directly to the Page Library's Content Type columns, and then take the Page Layout as the Meta Information prior to moving the content.

We were quite sure with this approach the existing migration tools would have worked for many kinds of scenarios.

Custom Built Aggregation Framework

Once we ran into a wall with the existing tools, we decided to try and use an internal content aggregation framework that we had been using extensively for years. This framework had both aggregation and transformation capabilities.

List Item Migration

Migrating items to a SharePoint List is relatively straight forward. List items in SharePoint are roughly analogous to database records, and one can insert items into Lists via Web Service calls or the SharePoint object model API.

We took the first approach, using Web Services, making SOAP calls to the exposed Web Service methods. The SOAP approach allowed us to log errors on a per record basis, giving us the ability to track the migration at a very detailed level.

Page Library Migration

SharePoint Page Libraries are more complex than SharePoint Lists. When migrating content into a Page Library, the content must be transformed into a SharePoint Page -- an entity more complex than a simple List item.

To accomplish this, the original content mark-up must to be parsed, unwanted tags need to be stripped and then mapped to the correct resource in SharePoint. Once the source content is parsed, cleaned and deconstructed, it can be stored in the respective native SharePoint fields based on the relevant Content Type (in our scenario, the Article Page).

After this it can be mapped to the relevant Page Layout. Page Layouts determine the look and feel of the rendered content, in accordance with the principle of separating content and presentation.

Note:
We could, in principle, also map to other Custom Content Types without an issue using this approach.

Page Libraries expose these pages in the format of XML with just the column / field as an element in this XML. Once the element was also the page layout that need to be used to present this Page.

This made our job easier. We made our framework generate the Pages in this format and import them into Page Library while applying the right Page Layout for presentation as listed in one of the elements in the XML.

In addition to this we also had to face the challenge of creating sub sites to replicate the content structure in SharePoint. It's important to note that this task added a lot of overhead to the migration project.

Final Thoughts

In a Page Library, every piece of content -- other than the Web Part content -- gets mapped to a corresponding Content Type column in the Page Library. And the Page Layout itself is one of the metadata which the system uses to apply the correct Page Layout during content rendering.