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.
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.
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
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 (firstname.lastname@example.org) 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 (email@example.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.