Things to Consider While Migrating Content from SharePoint On-Premises to SharePoint Online

Things to Consider While Migrating Content from SharePoint On-Premises to SharePoint Online

Mobility, big data, and social collaboration is on rise today. Businesses are looking for ways to convert these evolving trends into business prospects. Migrating content such as data, applications, and business lucidity from a secluded legacy collaboration and information sharing system to modern day online platform is a stride in the right direction.
With the advancement in technology, cloud has turned into a much more attractive option for organizations that want to eliminate complexities revolving around their services. The list of benefits offered by new SharePoint Online is quite huge, but still people feel hesitant in moving their important data or content to the cloud.
The most critical part of a SharePoint migration is planning for the migration itself. A successful migration from SharePoint on-premises to SharePoint online requires a complete planning and analysis. There are many types of migration activities, each with their own distinctive type of data to be migrated and necessitating a diverse approach. Despite of this fact, many organizations ignore the critical aspects associated with SharePoint Online migration.
So, in order to achieve efficacious migration here are few things that you must consider before moving content from SharePoint on-premises to SharePoint Online.

Placement and Migration Considerations
Very first thing that you must consider is whether your organization runs SharePoint on-premises or not. With the existing on-site SharePoint deployment the procedure of creating SharePoint farm and migration becomes easy. The migration process needs you to build a completely discrete SharePoint farm and then copy content and service application databases to the new SharePoint farm. Due to this you will have two discrete, parallel SharePoint deployments for a particular period of time. Depending upon the dimension and scope of your SharePoint deployment, you might need extra hardware to put up the parallel SharePoint farm.

Deployment Scale
Doesn’t matter whether you have existing SharePoint or not, you still have to consider the scale of the SharePoint farm you want to install. Usually SharePoint farms are dispersed between multiple servers as it allow organizations to accomplish fault tolerance and scalability for the SharePoint environment. In case of SharePoint on-premises deployment, it’s totally up to you to decide the number of SharePoint servers and database servers you need. It’s your responsibility to make sure all SharePoint servers are accurately licensed. SharePoint deployment can be complex to offer the preferred level of fault tolerance and scalability.
On the other hand, if you opt for SharePoint Online then you don’t have to take access burden of building the obligatory SharePoint architecture and this could be the most persuasive reason to deploy SharePoint in the cloud.

Cost Considerations
Other than the above two factors, cost is also a major consideration in SharePoint deployment. When it comes to office Web app costs, both on-premises and cloud based deployment allow use of Office Web Apps, but Office Web Apps are licensed differently.
With Office 365 subscription plan users can view Office documents online. But when it comes to on-premises deployment, there is no need to license Office Web Apps to view Microsoft Office documents. But if organization is using Office Web Apps for editing documents, then they must be licensed.

Data Storage Considerations
With on-premises SharePoint deployment you can accommodate unlimited amount of SharePoint data, by obtaining the required storage hardware. Whereas with SharePoint Online you’ll not get the benefit of including unlimited data storage.

Application Integration
Another major consideration is the integration of SharePoint on-premises with other applications. SharePoint server is more than just a server application, it’s a fully expandable web platform. Numerous organizations have put huge assets in customizing SharePoint to provide assimilation with a critical line of business applications, for instance, customer relationship management software, enterprise resource planning, etc.

To wrap up: Online SharePoint deployment is suitable for those organizations that don’t wish to take cost or intricacies of building a scalable and fault-tolerant SharePoint farm. Whereas, on-premises SharePoint deployments are better for those organizations that need better control over the farm’s architectural design or more storage than Microsoft provides. So, weigh up your case and then take the plunge. And, if you have decided to take the route to clouds then LepideMigrator for Documents www.lepide.com/lepidemigratordocuments can assist you to easily migrate content from SharePoint on-premises to SharePoint Online. Its comprehensible interface and easy execution process works like charm and helps achieve desired results with minimal efforts.

Author Bio:
Ajit Singh is associated with   "http://www.lepide.com/" Lepide Software as a Marketing and Communications Manager.

Awarded the SharePoint Server MVP 2014

I've received a message from Microsoft that told me I've been awarded the SharePoint Server MVP.
It is the first time that I got this award and I have to say that it is a nice award to start the new year.



Thanks to Microsoft, MVPs and community members :)
 

Content types publishing across site collections - SharePoint 2013

I was working on SharePoint 2013 project for operations management. We had to create an operations portal to manage projects. After analyzing the requirements , limitation and threshold,  we decided to create a site collection per project. The main reasons was :
  • A content database size exceed 200Gb to avoid performance issues and to be able to use default backup/restore operations.
  • Ability to use different database servers for differents projects
  • Ability to move a project space from one content database to another
One of the issues that we have encountred is content type management. We had to create the same content types in each site collection and for every change in one site collection, we had to replicate it on the others.

We had two choices to solve this issue :
  • Custom development
  • Use a default SharePoint feature
Solving the issue with custom development could take us time that we haven't. We had to search SharePoint features to see if the is something that could help us.

After some research, we found that the SharePoint Managed Metadata service could be helpful for us. We will use the content type publishing feature of the Managed Metadata service.

To configure the service we have to follow the steps below :
  1. Create a site collection (Hub) that will host the content types that will be published.
  2. Configure the Managed Metadata Service to connect to the recently created site hub.
  3. Configure the Managed Metadata Service proxy to consume content types from the created hub
  4. Create content types in the Hub site and allow publishing
  5. Verify that the published content types are available in the other site collections

1. Create a site collection (Hub) that will host the content types that will be published.
  • Create a new site collection
  • Go to site collection feature
  • Activate the feature



2. Configure the Managed Metadata Service to connect to the recently created site hub
  • Go to central administration -> Application management -> Manage service applications
  • Select the "Managed Metadata service" and click "Properties" in the ribbon
  • At the bottom of the page , put the adress of your newly created site collection in the "Content Type hub" field
  • Click "Ok" to validate. The hub adress could only be updated using powershell



3. Configure the Managed Metadata Service proxy to consume content types from the created hub
  • Go to central administration -> Application management -> Manage service applications
  • Select the "Managed Metadata service " proxy and click "Properties" in the ribbon
  • Only check the 3rd and 4th checkboxes
  • Click "Ok"



4. Create content types in the Hub site and allow publishing
  • Go to hub site collection
  • Create a new content type
  • Add your custom columns
  • Click on "Manage publishing for this content type"
  • Select "Publish" and then "Ok"
 


5. Verify that the published content types are available in the other site collections
  • You have to wait a little bit until the synchronization job is executed
  • Go to a site collection different from the "Hub site collection"
  • Go to "Site settings"
  • Under "Site collection administration" click on "Content type publishing"
  • We will get the content types that have been published from the "Hub site collection"
     

     


     

     


 

SharePoint 2013 Farm documentation tool (SPDocumentor)

I have been working on a SharePoint 2013 project and one of my tasks was to document the server farm.
Documenting the farm manually takes too much time and i wasn't able to buy a third party tool to do that work.
I decided to create an application to automate the documentation process.
I called the tool "SPDocumentor" and i've published it on codeplex.
https://spdocumentor.codeplex.com/releases/view/112882
In the current release, i'm just generating documentation of the farm and web applications. I'll be working on it to document the : "Jobs, Site collections, backups ..."
The tool uses the SharePoint object model to access farm information and the "DocumentFormat.OpenXml.dll" to generate the target word document.


 

Fixing blank lookup columns in SharePoint when creating new site from a site template

One of the common issues when creating a new site from a site Template is that the lookup columns values are blanks. The full scenario is as below :
  • Create a SharePoint site
  • Add lists with lookup columns
  • Insert some data in the lists
  • Save the site as Template with its content
  • Create a new site from the Template
When you access the list which contains the lookup column, you will notice that the lookup values are empty. The lookup values still exist but they are not rendered. We have to fix the list schema by updating some properties of the lookup column. Two properties have to be updated :
  • The Web Id
  • The List Id
There are two ways to fix the list schema :
  • Using C#
  • Using Powershell
We will see how to fix the error using Powershell. The script below will let you fix the column.

$web = Get-SPWeb "Your web url"
$list = $web.Lists["Your list name"]
$column = $list.Fields["Your column name"]
$lookupList = $web.Lists["Your source list name"]
#Updating the column properties
$column.SchemaXml = $column.SchemaXml.Replace($column.LookupWebId.ToString(), $web.ID.ToString())
$column.SchemaXml = $column.SchemaXml.Replace($column.LookupList.ToString(), $lookupList.ID.ToString())
$column.Update()
write-host "Column properties have been updated"
$Web.Dispose()
  
More details about the lookup columns on MSDN.



 

SharePoint 2013 resources on SDPS website


Microsoft has created a website for the SDPS (SharePoint Deployment Planning Services) program. Using this program, a customer can use his software assurance benefits to cover deployment and upgrade  planning services costs.
The web site contains many important resources that help Microsoft partners to improve their demo and PoC.
Here some key resources that I found on the website
 

August CU Updates for SharePoint 2013 has been released

The August  CU Updates for SharePoint 2013 has been released. Below are links for August CU.

  • KB 2751999 - SharePoint Foundation 2013
  • KB 2726992 - SharePoint Server 2013
  • KB 2775426 - SharePoint Server 2013 with Project Server
  • KB 2799821 - Office Web Apps Server 2013

  • Make sure to run the SharePoint configuration wizard after installing the update.