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.

• Verify Credentials - This migration selection will test to make sure that the credentials being used for migration are correct and will allow a successful connection. No data is migrated. Retry Errors - Free migration pass. Once a migration has completed successfully, Retry Errors can be run to retry only failed items.
• Recently we migrated a test/dev SharePoint 2013 farm from Hyper-V virtualization platform to VMware. This farm consists of two servers: - one hosting SQL instance and all databases; - the second.
• Hi everyone, we are planning to migrate share point 2013 on premise to online using metalogix tool. So i need test cases for migration. Can any one guide me please. Hi split As metalogix tool is a third party tool, I'd recommend to contact metalogix tool support team, you will get more information from there and more experts there will help you.

To note down the actual time taken for migration from the point of start of migration till successful restoration of the system, is one of the test cases to be executed and hence the ‘Time taken to migrate the system’ needs to be recorded in the final test report which will be delivered as part of Migration test results and this information will be useful during the production launch.

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.

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:

1. Move old content entities to SharePoint Page Libraries
2. Move old images to SharePoint Picture Libraries and link them correctly in the content entities
3. Move old documents and other assets to SharePoint Document Libraries and establish the correct links
4. Move other items like Events, Links, etc.. to corresponding SharePoint Lists
5. 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.

Sharepoint Migration Test Cases

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.

Following from this relationships, we concluded that any content migration tool that claims to support SharePoint must be aware of and support mapping source content blocks to the Page Library Content Type columns. We did not find this to be the case.

In addition, we think that it is time that Microsoft re-examined its Page Library concept. Like other content management systems, we feel that SharePoint should support the creation of hierarchical directories within Page Libraries. This would allow for easier categorization of content and remove the need to create separate sub-sites to represent hierarchy.

Robust document management is by far one of SharePoint’s most appealing features. This induces many organizations, small or large to migrate their documents from files shares to SharePoint as the first order of business when new SharePoint site is setup. But how do you go about migrating file shares to SharePoint? Do you move it all at once? The short answer is NO. In this blog post I will try explain some basic steps you need to do before moving your first file from file shares to SharePoint.

Sharepoint Migration Test Cases Johns Hopkins

“When migrating file shares to SharePoint, don’t just blindly drag and drop the files and folders from one location to another”

Step 1: Conduct Document Inventory

When you are moving from an old house to a new one, you rarely just load everything you had in a truck and move. You probably go through your rooms, basement, cabinets, closets and garage and decide to throw some stuff away in garbage. Same analogy applies with file shares and documents. You need to go through your folders and sub-folders and conduct a document inventory: Determine what will stay and what will be left behind (documents you will not need). Some of the examples of the documents that won’t be making the cut are really old files or duplicates of the files you have stored somewhere in other folders/location.

Naturally, SharePoint, been a Microsoft tool, is excellent about storing and managing MS Office files (Word, Excel, PowerPoint, etc.) as well as PDF. Latest improvements to Picture Web Part (confirm name) also allows to store images and videos pretty well as well.

There are particular types of files that are not meant to be stored in SharePoint. For those files you might want to consider keeping them on file shares or utilizing other specialized file storage applications:

• Software Code
• Various Program/Application Files
• Executables
• Extra Large files

Step 2: Categorize your files/documents

Sharepoint Migration Test Cases List

Now that you determined what will be moved to SharePoint, you need to categorize your documents. Yes, all of them are mixed together now on one shared drive or folder, but it will not necessarily be the case when you move them to SharePoint. Using the moving analogy example I did before, imagine that you are moving from studio apartment to three-bedroom house. You no longer need to have your office desk and bed you sleep on and kitchen table all in one room. You can now organize things better according to their function. Same applies to migrating file shares to SharePoint. At the moment, your repository probably contains a mixed bag of documents that have nothing in common: Project Files, Policies and Procedures, customer documents, department files, etc., etc. You need to determine what are the different categories of chunks of documents that you have.

Why do you need to do that? Well, because like with the moving example above, these documents really belong on different sites in SharePoint.

There are 2 reasons why you MUST upload DIFFERENT CATEGORIES of documents to DIFFERENT SITES in SharePoint: Function and Security

Migration Test For Food Packaging

Your Policies & Procedures documents most likely need to have different security than your project files or customer files. The best practice is to create totally separate sites by function or security. Don’t recreate the mess you currently have on your file share!

Step 3: Assign Metadata Properties for each category

From my previous blog posts, you probably already know that I am a big advocate of using Metadata in place of folders. SharePoint is really powerful and highly configurable tool to help you manage documents using metadata. Take advantage of that! I have written a detailed, step-by-step guide on SharePoint metadata which will give you some ideas on how to come up with metadata properties and implement in your environment.

Sharepoint Migration Test Cases Graph

So here we go – these are the first 3 steps to successful SharePoint Migration. The whole migrating file shares to SharePoint thing is obviously more complicated than these 3 steps. You need to worry about lots of other things which I have already documented or will do so in future posts. However, before you acquire some fancy migration tool, I suggest you first get a grip on your repository and have a good understanding on the universe of documents that you have.