A very common request I receive is about migrating an on-premises SharePoint installation (typically Companyweb on Small Business Server) to Office 365. I have done a few previous blog posts on the topic but I think it is time to revisit this topic and share the challenges and ways I have overcome these.

Start fresh

The initial starting point for any SharePoint migration should always be asking the question, is it quicker, easier and better to start from scratch? Most smaller on premises SharePoint installations don’t contain a lot of data and have generally been thrown together in a very ad hoc manner. In this case, it is probably best to consider the migration to Office 365 SharePoint Online as an opportunity for a ‘fresh beginning’.

Any SharePoint environment should be governed by a least a little planning and forethought, which I can assure you will pay huge dividends down the track. So, if you are starting again, take a moment to do some planning and understand exactly what you want from SharePoint Online using the experience you have gained from previous on premises installation.

Copying files

As the size and complexity of local installations of SharePoint grows so too does the reluctance to start again, which is totally understandable. However, it is important that in most cases you can’t simply ‘move’ SharePoint for reasons I’ll go into shortly. You can however ‘move’ file data by simply mapping a drive to the source and destination and copying / pasting between locations. the downside of using this method is that you are going to only bring the files across, not any of the associated properties such as previous versions, check ins, workflows, etc. However, if SharePoint has simply been used as a document dumping ground then just map a location using Windows Explorer for the source and destination, then drag and drop between them.

To get a better understanding of how to map a drive in SharePoint have a look at my video:

Uploading documents to SharePoint Online

Templating

More complex SharePoint sites also typically contain other things such as calendars, contact lists, announcements and so on. These can’t generally be copied directly across they need to be migrated.

If you are migrating between identical versions of SharePoint i.e. 2013 on premises to Office 365, then you can template the source elements, including the data contained within, and then import into the destination. A fairly arduous task if there are are lots of different elements but provided you have SharePoint 2013 on premises the process is pretty straight forward.

This video of mine will give you a basic idea of how to template a site:

Saving a SharePoint Online site as a template

Migrating between different versions of SharePoint

The challenge arises when you DON’T have SharePoint 2013 on premises. This is the case with Small Business Server (SBS) which has SharePoint Foundation 2010 (SBS 2011), Windows SharePoint Services 3.0 (SBS 2008) and Windows SharePoint Services 2.0 ( SBS 2003). The rule with SharePoint is that you can’t take a template from one version and use it on another version. Thus, you can’t take a template of something from SharePoint Foundation 2010 and import it directly into Office 365, it needs to be migrated.

The first solution to this problem is to upgrade the on premises version of SharePoint to SharePoint 2013 so it matches that in Office 365. For SharePoint Foundation 2010 this means a single upgrade to SharePoint Foundation 2013, However for WSS v3 this means 2 migrations, the first to SharePoint Foundation 2010 and the second to SharePoint Foundation 2013 and then to Office 365. You can probably guess the story for the upgrade of WSS v2.0. It needs to be migrated to WSS v3, then 2010, then 2013 and then to Office 365.

SBS is also a special case (as it always is) in that you should NOT be upgrading it as it will break everything. Thus, doing an in place upgrade is not an option for SBS (and besides SharePoint 2013 no longer supports in place upgrades).

Typically this on premises migration is done using a database swing process which basically copies the old database to a new SharePoint server installation and then attaches it using a command line option. During this process the old database is upgraded to the new SharePoint version. if you want to learn more about this database attach method I suggest you consult my freely available comprehensive SharePoint Guides at:

SharePoint Foundation 2010 Guide

Windows SharePoint Services Guide

Thus, an upgrade from WSS v3 is going to mean two database swing migrations even before attempting to got to Office 365.

It is important to be aware that any SharePoint migration from an old version will never be prefect. Some features (if utilised in the old version) are not available in the never version. The main change is the fact that things look very different when you migrate SharePoint versions doing a database swing.

Third party tools

The better way to approach the migration process is to use a third party tool that will not only move the data but also upgrade the information on the fly. I have spoken previously about some options I have used:

Migrating from Companyweb to Office 365 SharePoint

but by far and away the best is Sharegate. It is very simply to use, yet extremely powerful to use. It truly makes migration from previous versions a breeze.

A good example, is that I recently used Sharegate to migrate from a 12 year old on premises WSS v2 installation to Office 365 with success. It wasn’t exactly straight forward but Sharegate made life so much easier than doing it any other way.

The challenge with Companyweb

There still remains a challenge with SBS systems because third party tools like Sharegate require direct access to the SharePoint site. This works fine if you are on premises running Sharegate from a workstation on the network but what if you want to do it remotely like I was? It’s simple. You can’t without major changes to SBS and your local firewall configuration because Companyweb is effectively hidden behind Remote Web Workplace (RWW), meaning there is no easily way to provide direct access.

The solution was going to be to copy the SharePoint site to a new stand alone server that was configured to be directly on the Internet and then use Sharegate. This is going to mean the need to run a copy of WSS v3 somewhere.

A while back I detailed how I used to do this using on premises virtual machines hosted on a laptop but I now had this set up in Azure:

I finally get Azure

What I have there is two things I need to complete this task. Firstly, I have a demo WSS v3 machine, fully patched and secondly I have a workstation on which I have Sharegate installed.

Thus, the next task to accomplish was getting the WSS v3 server in Azure up and running with the data from the on premises SBS instance. This meant getting a copy of the on premises SharePoint databases and attaching them to the WSS v3 installation in Azure. The trick was getting the on premises SharePoint database into Azure given that it was a few gigabytes.

The solution to this upload problem is relatively easy. What I did was create an Azure SMB file share per:

Creating an Azure SMB fileshare

and had the on premises SharePoint databases uploaded here by simply mapping a drive letter to Azure from a local workstation.

Once the database was in Azure I simply mapped that same SMB file sshare to my WSS v3 Azure virtual machine and copied the databases to the appropriate location on the virtual machine. I then attached these uploaded databases to WSS v3. Once complete, I then had a direct copy of the on premises SharePoint server but now directly accessible via the Internet.

I then fired up my Azure VM with a copy of Sharegate on it. I connected Sharegate to the source WSS v3 site, now in Azure, and the destination Office 365 SharePoint Online. I configured Sharegate appropriately and then stepped back to let it do its magic.

You may be asking, why didn’t you just run Sharegate on you local machine? Why do you need to use a virtual machine hosted in Azure to run the migration tool? Here’s why kids. I learnt during an early SharePoint migration that things ALWAYS take far longer than you expect. In my case I was on the client’s premises still doing the migration as the end of day approached. I couldn’t easily leave because that would mean stopping the migration and returning when they reopened, since I would need to power off my local workstation. I therefore figured out that if I did everything in an Azure virtual machine I could simply disconnect and leave the VM running and not interrupt the migration. I could then easily relocate elsewhere and reconnect to the still running migration session. Much more flexible I think you’ll agree, so that’s the way I do all migrations now. You gotta love Azure don’t you?

Once the Sharegate migration was complete, I checked the logs and the destination. I then let the client know that the migration was complete and they should check the result to ensure they were happy. Of course there still things that will need to be fixed because the source site did things not supported in SharePoint 2013 and used bad practices like direct URL links, but these are relatively minor problems and easily rectified. In one swoop, the site was upgraded from WSS v3 to SharePoint 2013 and moved to Office 365. The power of third party tool ins action. Thank you Sharegate.

Sharegate is a fantastic tool but the its only downside is the fact that it is rather expensive. This puts it out of the reach of most small businesses and resellers, especially if they only need to do a single migration. I have put a case to Sharegate that they look at a cheaper offer for SMB. Hopefully they’ll be open to that but in my opinion, Sharegate is the premier tool for SharePoint migrations, bar none.

Migrating on premises SharePoint to Office 365 is a challenge and there are many ways of approaching it (SBS even more so). To do a complete content migration in one swoop you’ll need a third party tool, and I have said, my recommendation is Sharegate. However, if you don’t have the skill set to do this or find Sharegate a bit beyond your budget then you really need to contact me (director@ciaops.com) so I can help you. Hopefully, as you can tell from this post, I do this sort of thing a lot and have the tools and set up to streamline the process and therefore make it far more cost effective for those smaller and one off migrations. So don’t be afraid to contact me directly (director@ciaops.com) for advice and assistance for your on premises to Office 365 SharePoint migration. I’m here to help.

Please support my free content efforts at http://patreon.com/ciaops where as a supporter you can access other benefits.

Today is a GOOD DAY! Microsoft have delivered on their promise to increase the default starting Team Site pooled storage from 10GB to 1TB as announced in this blog post:

Auditing, reporting and storage improvements for SharePoint Online and OneDrive for Business

and I quote:

1 TB additional space for overall pooled SharePoint Online storage allocation

The amount of content in Office 365 is growing 300 percent year over year. To meet your needs for more storage, we’re increasing default storage to 1 TB plus 0.5 GB per user to use across SharePoint Online, Office 365 Groups and Office 365 Video—up from the previous allocation of 10 GB. This is in addition to the unique default per-user OneDrive for Business storage space and individual storage provided for user email inboxes.

I can also happily report that I am seeing this increase inside my own tenant already:

It has taken quite a while to get the old 10GB limited upgraded to 1TB and that is going to make life so much easier for businesses moving to Office 365. This is because the area in which shared information for people needs to go is into Team Sites NOT OneDrive for Business as I have said many times. Now having 1TB as a starting point means most businesses won’t need to purchase additional space for their shared information. It should also place the focus back on the more powerful Teams Sites for business information and away from OneDrive for Business which is designed for individuals.

I really believe this is such an important upgrade and will remove one of the major restrictions businesses have had around moving from traditional on-premises servers to Office 365.

Happy days!

A while ago I detailed how to set up SharePoint Drop Off Libraries so documents would be automatically routed within a Team Site. You’ll need to review that post:

Working with SharePoint Drop Off Libraries

because this post will show you how to route documents using Drop Off Libraries between two different Team Sites.

The most important thing you need to ensure is enabled in the source Drop Off Library location is that the option for Sending to Another Site is enabled in the Content Organizer Settings as shown above.

You’ll then need to follow the same procedure as the the initial post detailed about enabling a Drop Off Library in the destination Team Site. You’ll need to configure the appropriate rules so that any document uploaded to the destination Drop Off Library ends up in the correct location within that local Team Site.

To link the source Drop Off Library to the destination in another location, navigate to the Content Organizer Settings in the destination site. Scroll to the bottom of the page and there you’ll see a heading Submission points as shown above. Copy the URL that is shown there. that URL should end with something

/_vti_bin/OfficialFile.asmx

You’ll then need to navigate to the SharePoint admin center and select the Records Management option from the menu on the left.

Select option New Connection, then paste the URL into the Send to URL box as shown above. Also, enter a description into the Display name field, make any other changes and save the configuration.

Now navigate to the source Drop Off Library location and create or edit a Content Organizer Rule. Complete all the details as before but for the target location, as shown above, you should be able to select a target as Another content organizer in a different site. You should then be able to select the connection display name you just created in the SharePoint Admin center. Save the rule when complete.

In this case, there are now two rules for the source Drop Off Library based on what is entered into the Title field. One rule routes to a local Picture Library in the current site (the top rule), the other routes to a Picture Library in a completely different Team Site (the second rule).

If a document is now uploaded to the source Drop Off Library and submitted with the appropriate condition (here the Title field is set to Team).

The document is corrected routed to the subsite as shown above.

Where it is the routed by the local Drop Off Library to the final destination as shown above.

So in summary, to route a document from a source Drop Off Library to a destination library in another Team Site requires configuring a connection to the destination in the SharePoint admin center, then using that connection as the destination for the Content Organizer rule.

A little bit of configuration, but once operating it provides a powerful way of automatically routing documents to the correct location ANYWHERE with SharePoint Online. That means less time is wasted by users working out where to put documents and secondly it allows routing to multiple location using rules. Thus, you could in theory have a single drop off point in SharePoint routing to various locations. Now wouldn’t that make life easier for everyone?