Client Pay Portal
 migrate to the cloud

How to Migrate from SharePoint 2010 to SharePoint Online

Welcome to the Future!

Microsoft’s latest version of their industry-standard intranet platform, SharePoint, is slated to release soon. In fact, the public beta of SharePoint 2016 is already available. SharePoint typically sits on a server (or more often, multiple servers!) on premise at a business’ location, and all the users logged into the local domain then have access to the benefits of SharePoint’s enterprise intranet.

Whenever a new version of SharePoint is released, upgrading from a previous version is not as simple as running a quick background software update. It’s an involved process, which is really a migration rather than an upgrade. This is why if you’re running an on premise version of SharePoint and are considering the upcoming upgrade, now is the perfect time to consider migrating to SharePoint Online, instead.

There are lots of advantages to SharePoint Online over SharePoint on premise (that I intend to blog about in the future), but the best reason is probably the fact that this will be the last SharePoint migration you’ll have to do because Microsoft will take care of all updates in the future. 

Planning the Move

I would love to say that upgrading to SharePoint Online is as simple as upgrading your PC to Windows 10, but sadly that’s far from the truth. Migrating can be a very complex process with lots of compatibility wrinkles to iron out before you can switch your users over to the new system. The most important step in moving to SharePoint online is preparing for the move.

In this article I’ll cover some of the steps, I perform when migrating a company from on-premise SharePoint to SharePoint online.


Quantum States

Migration happens in stages, but before you can migrate Document Libraries and Lists and other objects to SharePoint Online you’ll first need to get your users set up. In fact, you’ll need to enable your company's users to exist in two places at once; both in your local Active Directory and in the Office 365 online tenant. This must be done first so that permissions and file ownerships transfer smoothly without breaking anything.

So before you can begin the migration, you'll have to start synchronizing users from your local Active Directory to Azure AD. This is known in the "biz" as federated services and causes high blood pressure in IT professionals everywhere. Here are the steps you'll take to get this setup.

Establish Trust

The first step to synchronizing your users between your local on-premise Active Directory and Azure AD is to establish trust. This establishment of trust tells Microsoft that you are the rightful owner of your domain name so that a hacker can’t try to set up a tenant with your domain name.

Once you've set up the Office 365 tenancy, and logged in as the Global Administrator, you'll go to the Admin Dashboard of your Office 365 tenant and add a domain.

manage domains office 365
The steps that follow after this vary from company to company depending on where your domain name was purchased and how your DNS is managed. But in this part of the process, you'll be given some very specific instructions to insert a custom identifier in your DNS that Microsoft can look up to verify you really own the domain and have the credentials to administer it.

Configure and Turn on Synchronization

Once Microsoft has confirmed your ownership of the domain, you’ll need to activate Active Directory Synchronization for your tenant, which is also done in the Admin Dashboard of Office 365.

configure office 365 sync
At this point, we'll move away from Office 365 and onto your local domain. Office 365 is now expecting to hear from Active Directory (AD), so this is where you install the Active Directory Synchronization tool (dirsync.exe) on your Active Directory Server. Microsoft provides this tool to facilitate communication between on-premise and online AD. You can download it, and its cousin IdFix, from the Admin Dashboard.

Active directory IdFix window
Run IdFix first, to catch any glaring issues in Active Directory, and then run DirSync to connect to Azure AD. Active Directory is a lot more forgiving than Azure Active Directory, so it's important to sanitize the user list for anything that will throw an error in Office 365.

Set a Sync Flag in AD

Active Directory contains lots of records which it uses to manage your local domain, and they’re not all users. You will not need all of the records to be pushed to Azure AD, so we need a way to tell DirSync, which users to synchronize. One easy way to do this is to filter the DirSync tool to only migrate certain OUs (organizational units), but this may not always be feasible.

Since each user in Azure AD will need to be licensed individually, you’ll need to create a list of the users that you want to have access to SharePoint Online. You can create this list as a simple text file, with each line containing each user's login name. I've written some PowerShell magic to process this list and add a variable to each user, which flags DirSync to synchronize their information and password with Azure AD.


Force Sync

DirSync will keep track of changes in Active Directory, and periodically check in with Azure AD and push any changes that have happened. However, the first time we set this up we need to force a sync. Any time a user changes their domain password, this will also force a sync. This change will likely take a few minutes, so it's time to make yourself a cup of coffee and let Active Directory do its thing!


Verify Sync

Finally, we need to see if everything worked. Log in to the Admin Dashboard of Office 365 and click on Active Users (under the Users section) and verify that DirSync has successfully pushed the users you specified. Each one should be marked with “Synced with Active Directory” under Status. All of your synced users are now able to login at with the same credentials they use on your local domain.

verify office 365 sync

Wrapping it Up

Once these users are migrated, you’ll still have to purchase Office 365 licensing for them, and assign them to the users. I have also written PowerShell scripts to automate this process. As soon as that is taken care of, your users will be able to login at with their same credentials they use on the domain on your network.

Many people doubted that SharePoint 2016 would even be released because Microsoft is recommending that businesses and organizations using SharePoint on-premise move to the cloud-based solution. In fact, SharePoint 2016's main purpose for existing is to make the transition to SharePoint Online easier and is designed for a hybrid environment between on-premise and online tenants.



Samuel O. Blowes, Director of IT
Samuel O. Blowes

Director of IT