Here is an outline of some more areas that can be challenging when migrating your on-premise SharePoint environment to Office 365.
This is building off one of my previous posts, check it out for more information.
Here are some things to watch out for:
Hard-coded URLs
One of the great things with SharePoint is its use of Relative URLs. This allows you to quickly and easily pick up and move a site, or reorganize it in the existing site collection, and not break all of the links you may have created. Unfortunately, many users are not aware of how relative URLs work, or even what they are!
Essentially a relative URL knows where it lives relative to the overall site structure.
For example: https://www.acme.com/sites/engineering/tools is a full URL that gets you to the ‘Tools’ site. The Relative URL for this would be: /sites/engineering/tools. This removes the host header from the equation, and SharePoint knows you want to get to the ‘Tools’ site underneath whatever web application this may reside on. However, most users don’t realize that, and they may utilize the full URL when crafting their content. This becomes known as a hard-coded URL.
Now, in an on-premise environment, if you were to migrate to a new SharePoint environment, you could create DNS entries to handle this. With SharePoint online, however, your new SharePoint URL will be a *.Sharepoint.com address.
Office 365 does not allow you to use Alternate access mappings and DNS to workaround hard-coded URL’s, so this could become a big sticking point when you’re migrating hundreds of gigabytes of content to Office 365 as all of these hard code links will break. Depending on your migration software, this can be handled at the time of migration, or you can purchase a 3rd party tools that can scan Office 365 and replace those broken URLs with the correct ones.
Migration Software – You’re Going to Need It
When making the choice to migrate your content to the cloud, the first thing that can be overlooked when beginning this type of project is budgeting for a migration software package. Microsoft does not provide any good free tools that will properly migrate your content, and a third-party tool is really a must when you decide to make that leap.
There are multiple vendors that provide migration software packages (Metalogix, AvePoint, ShareGate, Dell), but since every SharePoint environment may have its own unique design and content some of these tools may have issues with migrating. Each tool has a free trial, and I highly recommend performing test migrations with each one before you select a tool. The last thing you want to do is purchase a product and then find out later that it can;t properly migrate all of your Content Editor Web Parts.
Don’t make it an Apples to Apples Migration
You may have done some really neat things with your on-premise migration: You really customized the branding, added lots of really cool JQuery and JavaScript functions, or really utilized the Content Query web parts to make things extra dynamic. But remember: Your performance experience and supportability experience will change once you are Office 365.
Microsoft has no issue upgrading your tenant behind the scenes and rolling out new features when they are ready. Web Parts that may have performed quickly on your environment may not be optimized for a cloud experience. Do your best due diligence to ensure you are following best practices for performance on Office 365, and be ready to flex your design as needed to ensure your users have a good experience on the new platform.
Estimate the amount of time you think it will take to migrate your content. Then double it.
Remember, you’re moving content from your extra-fast LAN and onto the Internet; this may not be as fast as you hope. The good news is, Microsoft allows you to ship hard drives to them to help speed this process along, but depending on the type of migration you plan to perform, this may not be an ideal option. So, do some test runs of large chunks of content to get a feel for the amount of time this will really take. And Remember: Uploading (1) 1GB file is a lot faster than (1,000) 1MB files. Read/Writes will take their toll on your network overhead.
