SharePoint Online Manual Migration

I worked with a couple of SharePoint Migration Project i.e.  On-Premises to On-Premises & On-Premises to Online using 

           Manual Approach ( Content DB Attach)

           ShareGate Tool 

           ShareGate Tool based PowerShell scripts.

           Manual Approach

In this article, I am going to articulate approach and scenario, where we used SharePoint Online Manual Migration approach.

Scenario: -

Migrate small size of content i.e. List & Library ~ 4-5 GB to SharePoint Online.

Why I chose manual approach?

Tool is really required if we have >25GB of content and another factor like:-

• changes in Application Architecture (Restructure the Content DB).
• Changes in Information Architecture or Schema.
• Version History needs to maintain.
• Metadata need to maintain i.e. Created By, Created, Modified and Modified
• Easy to get Pre & Post Migration reports & Verification.
• Incremental is just configuration away etc.
• Content Size is huge, Easy to schedule a day-night jobs.

Note: - Migration Tool use Content Migration API, which need cloud storage account. It also come up with extra cost along with Tool.

IF all above factors are not so important, we can easily use manual migration instead of tools.

How Manual Migration Done

Save Site as Template is not really possible using below factors:-

·         Publishing Site Template.

·         Publishing Feature activated in the site.

·         Sometime Managed Metadata Column and weightage of list column

2.       Save List as Template

This is one of easiest way to backup and restore the content. Even it support lookup column, 

If List backup and restoration configured in proper order i.e. First Parent then Child list.

Browse the List -> List Settings -> Save as Template. It will create and store the .STP file in the catalog library.

Another approach to create the STP file is PowerShell.

Both way, we can create the .STP file using Content or without Content.

Copy Data via Access:-

In some case, you have to use Access to move the content to Cloud. 

Select Open with Access

Specify the Path with filename or List Name, which create the access database (.accdb)

Two option available:-

• Link to Data on the SharePoint Site
• Export a copy of data

Once you download access database, Open the Database and select the list and Select SharePoint under Move Data Ribbon group. It prompts for destination list.

Once you complete above activity, you content will reside in the SharePoint Online List. It successfully support lookup column also.

Limitation: - If you have lots of view, It doesn’t maintain the sequence of column. Need to do again manually or using PowerShell script.

Copy Data via Excel:-

Use Export to excel, It export all list data into excel.

Below is the example of exports data.

Navigate to SharePoint Online List and click Quick Edit – It allow to copy paste the data from excel to list.

After copy the content, Its look like, At the one time, you can copy paste 500+ items also.

Click on Done and Job Finished.

Library Files:-

File Explorer View or Drag & Drop.  But it doesn’t allow more than 100 files at the same time.

Access allows you to copy list over to the cloud. But you can't use it for Libraries.
To copy files, use "Open with Explorer"

You still can copy these files by dragging and dropping directly in the document library:

When Manual Approach doesn’t suit (i.e. .STP file)

It doesn’t support two level below i.e. Moss2007 or SP2010 to O365. It is possible from SP2013 to O365.

How to set read-only

Once you transferred the data from source to destination, you must make sure that source data will not change. Manual Migration is tedious job and do the incremental is more tedious.

This can be achieved using Break permission inheritance and change to Read. Prioritize the list & library which are not updated frequently also help to avoid incremental for all.

Note:- Version History, All minor version should be published as major or discard.

Summary

If you have customization, you need to think, Can we convert to JS-Framework using REST or Search API, List form level customization using JS-Link.

If left behind customization, up to 4-5 GB content migration, we achieved in 8-12 hours jobs to avoid the incremental approach. To analyze and prepare the scripts and order of list took 2 weeks of time.

Handle Multiple Domain during SharePoint Migration

This blog describes the problem statement and resolution i.e. How to handle multi-domain issue during SharePoint Migration.

This is quite interesting & common scenario, which we face in almost all migration project i.e. On-Premises to On-Premises or On- Premises to Online.

SharePoint Migration project easily enters into escalation mode due to multi domain users after entire application migration.

Somehow application team tries to convince the business user to adapt or change the User Name with a NEW domain. This is something no business user ready to accept.

Scenario illustrated in below diagram:-

Problem Statement:-

Before Migration, Project was using Domain OLD.com and application URL like https://sharepoint.old.com where the user also have their login id like <<Domian>>\<<USerName>> old\user etc.

Business wants to migrate the application to different domain i.e. On Premises or Online.

New Domain like NEW.com and application URL like https://sharepoint.new.com

Users, who are part of the NEW domain can easily recognize by control and start using the application but some users are still part of the old domain.

As our new migrated application hosted into new domain so old domain user doesn’t recognize into new domain application.

 Below are the ways to resolve the issue:-

Option 1:-

If both domains have  TWO WAY TRUST. No configuration required. the user can be added as <<OLDDomain>>\<UserID>; instead of only user name.

 Option 2:-

If both domains have ONE WAY TRUST. Only people picker control configuration need to do using PowerShell. It will help control and application to recognize the user.

Option 3:-

 If both domains don't have TRUST process. User Profile Synchronization needs to perform. It will help control and application to recognize the user.

Ref :- https://collab365.community/sharepoint-2013-people-picker-problem-with-2-way-trusted-domains/

Estimate The Time Frame To Migrate Content To SharePoint Online

This article focuses on the actual content migration effort which is separate from planning, redesign, fixes, deployment, and configuration.

It's a very common question during the analysis phase of a SharePoint migration project. - How much time a "Tool or Migration API" will take to migrate the actual content from the source to the destination?

I found a couple proposals where people simply say 5GB per hour but it's not really practical.

It depends on multiple factors. I am not going to dive deep into how the below factors impact this. Just take the estimation based on content.

• Network bandwidth
• Type of content & file format i.e. List Item, Document, and Video etc.
• Check In / out files & Versions
• User base, Custom Permission & Groups
• Workflow (OOTB, Design. Custom, Nintex)
• Customization
• Asp.Net Forms, InfoPath Forms
• Threshold limit (Items, Lookup, Unique permission)

High-level content migration estimation view 

 List Item size is very low and associates with the large metadata, Workflows, Events etc.

• Library item size quite big (files size like MBs) associated with versioning, large metadata, workflow, events etc.
• File Share – No metadata, No Versioning
• Video – Big size files.

How Migration API (Most of the tools use) works

How does version impact the estimation (which we usually miss)  

Deployment Steps For InfoPath Form During Migration

Checklist

• SharePoint Enterprise Edition 2013
• Microsoft InfoPath Designer 2013
• An account to access the SharePoint 2013 Site as Site Collection Administrator
• Visual Studio 2012

Step 1 :- Open InfoPath Form:

Open the 2007 InfoPath template (XSN file) with InfoPath Designer 2013

Step 2 :- Go to Form Options:

File->Options->Form Options

 

Step 3:-Set Full trust for the form Security and Trust

 

Step 4:-Set Code path and Target Version for InfoPath.

In Our case we had a code behind for the InfoPath form, so set the project file under Programming.

Target of the Form should be InfoPath in the Target dropdown.

 

Step 5 :- Change Compatibility

Change the Form type from Web Browser Form (InfoPath 2007) to Web Browser Form and set the Url of the site.

 

Step 6:- File -> Publish-> SharePoint server

 

Step 7:- Give the URL of the site where this form needs to be published.

 

  

Step 8 :- Click on next and select Administrator-approved form template

 

Step 9 :- Click Next, Configure the path where the form needs to be published

 

Step 10:- Click Next

 

Note: User can modify the InfoPath fields here, if required.

Step 11:- Click Publish

 

Step 12:- After its successfully published, click Close

 

Command to deploy the form to central admin (as earlier it was deployed to central admin)

Install-SPInfoPathFormTemplate -Path "Path of the xsn file"

Enable-SPInfoPathFormTemplate -Identity "Agreement Form.xsn"  -Site "SiteCollectionUrl"

If you want to re-deploy in the same farm, follow these commands:

1. Disable-SPInfoPathFormTemplate -Identity "Formname.xsn" -Site "SiteCollectionUrl"
2. Uninstall-SPInfoPathFormTemplate -Identity "Formname.xsn"
3. Install-SPInfoPathFormTemplate -Path "Path of the xsn file"
4. Enable-SPInfoPathFormTemplate -Identity "Agreement Form.xsn"  -Site "SiteCollectionUrl"

Form will be deployed to Central Admin.

Challenges faced during InfoPath form Migration from Moss 2007 to SharePoint 2013

​

Challenge 1:

During Migration from Moss 2007 to SharePoint 2013 - all  old infopath forms that exists in Form/Document  library were opening /working  with new InfoPath 2013 form, but People picker does not contain any value.

Note:-

This is due to schema structure of People Picker control has changed from Moss2007 to SharePoint 2013.

Resolution:

Since the people picker in InfoPath 2013 is changed, we had to add extra namespace to all people picker tags in the InfoPath xml files in the library.

Example: Project manager people picker was not having any value in the form.

Before adding namespace

<my:project_manager>

<my:Person>

<my:DisplayName>xyz</my:DisplayName>

<my:AccountId>domain\xyz</my:AccountId>

<my:AccountType>User</my:AccountType>

</my:Person>

</my:project_manager>

After adding namespace

<my:project_manager>

<pc:Personxmlns:pc="http://schemas.microsoft.com/office/infopath/2007/PartnerControls">

<pc:DisplayName>USer Dispaly Name</pc:DisplayName>

<pc:AccountId>Domain\user</pc:AccountId>

<pc:AccountType>User</pc:AccountType>

</pc:Person>

</my:project_manager>

Once the above change has been done to all old xml files using PowerShell script, People Picker started working fine.

Challenge 2:

In continuation of above Custom Migration from Moss 2007 to SharePoint 2013  article:-

I need to deploy the custom workflow which was associated with Info Path Form. As I migrated info path and workflow successfully. It was not working as expected.

​After doing lots of R&D, I got the solution and explained below:-

Resolution:

In the Nutshell :- Custom Workflow code was using an entity class file auto generated for InfoPath XSD file. As People Picker control scheme has changed from Moss 2007 to SharePoint 2013. So I need to update the entity class accordingly.

Generating new entity class

To generate the entity class for .xsd file we need to use the XML Schema definition tool (Xsd.exe)

Reference links:

https://msdn.microsoft.com/en-us/library/x6c1kb0s(v=vs.110).aspx

http://blogs.msdn.com/b/yojoshi/archive/2011/05/14/xml-serialization-and-deserialization-entity-classes-with-xsd-exe.aspx

Once you have the SDK Installed(either Manually, or with Visual Studio), you'll find it in the following directories:

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools

Run the command as

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools>xsd.exe

/c /l:cs myschema.xsd BuiltInActiveXControls.xsd

Note: myschema.xsd is file name of InfoPath and BuiltInActiveControls.xsd was needed for new people picker in InfoPath 2013

This will generate the entity class for the .xsd file of InfoPath. Then replaced this with old entity class carefully and check if only people picker classes has changed and deployed the solution.

Now workflow started working as expected.

Note: 

Resolving Issue with People Picker In InfoPath Form

​Since picker schema in InfoPath 2013 has changed, so we have to remove existing people picker and add new people picker from InfoPath 2013 also.