Apr 5, 2019
I know, I know, there are already tons of SharePoint migrations to Office 365 “Best Practices” articles out there. My evil twin even wrote an article on how to fail a migration recently, which received much more attention than it deserved.
I have done many large scale migrations and given many presentations on the topic, but I didn’t want this article to be a “things Hugo says you should do” article. There are many other authors who are much more insightful and eloquent.
This article is a compilation of the best “best practices” articles I could find. I have included the list of articles at the end.
By all means, do not trust that my conclusions are accurate or unbiased. Feel free to read all the referenced articles and make your own conclusions — and then comment below!
I searched for SharePoint to Office 365 Migration Best Practices on Google and Bing and compiled all results.
I did not include articles that were behind a paywall, or those that required you to provide an email to get access to the article/download anything.
I also excluded any articles that were purely technical (e.g.: the ones that show you how to use a migration tool).
After carefully reading each article, I create a table listing each article with every “best practice” idea discussed in the article.
When looking for best practice criteria, I looked for articles that focused on the following outcomes:
I tabulated the best practices that appeared in 3 or more articles.
I focused on the top 10 best practices but ended up with 11 topics. I chose to separate Clean Files and No “as-is” because — while they are arguably similar — most authors discussed both points separately.
The list below provides links to each of the articles reviewed. I chose to use a legend (instead of writing each best practice in the header) because I wanted the table to be easy to see at a glance.
Legend
The following letters correspond to a best practice idea. We’ll discuss each idea below.
A
Incremental
B
Inform Users
C
Analyze/Audit
D
Plan
E
No “As-Is”
F
Accurate Estimates
G
Clean-up
H
Train Users
I
Information Architecture
J
Not just an IT initiative
K
Test
L
Champions
Many authors agree that you should migrate your content incrementally, or in batches, rather than migrating everything at once.
For example, you should consider migrating content on a team-by-team basis. Doing so gives you the opportunity to properly analyze and audit the data to be migrated, clean up the data and re-organize it as you migrate, and spend quality time with the users to inform them and train them.
It also gives you the opportunity to test each migration and — more importantly — to get your content owners to verify (and possibly sign-off) on the migration.
Getting sign-off from content owners is a great way to help speed up the decommissioning of the old data (which is a re-occurring best practice, but didn’t make the top list).
The topic of “Informing Users” and “Communicating” was one of the most common best practices. Most experts agree that you should inform your users in advance about the exciting new platform they’ll soon be using, describe the benefits of the new platform, and inform them of timing.
Migrating to Office 365 impacts users. Your users may make up their minds to “boycott” the new platform before they even see what’s coming.
This is often due to fear of the unknown from your users.
Take the time to explain to your users what’s coming, how they will benefit from this migration, and when it will happen.
You can’t expect users to drop everything they’re doing for your migration. Try migrating the accounting department during fiscal year end and you’ll see just how much push back you can get from your users.
The # 1 best practice seems obvious, but it is often forgotten.
Before migrating, you should perform an in-depth analysis of the content you’ll be migrating. Don’t just count how many files there are!
Consider the following :
Not all content needs to be migrated (see Clean Up, below), but every piece of content should be accounted for. While most of your files may be migrated, some may be archived or skipped because they are duplicate. Keeping an audit of all your content, along with their migration status will help ensure that all your content is accounted for.
A successful migration begins with creating a migration plan.
This is what I typically put in my migration plans:
- Objectives and Goals
* Business-Related Goals
* Migration-Related Goals
- Migration Strategies
* Strategy 1
* Tools
* Implications
* Strategy 2
* Tools
* Implications
* ...
* Strategy n
* Tools
* Implications
- Migration Environment
- Migration Guidelines
- Migration Process
* Preparation
* Migration Step 1
* Migration Step 2
* ...
* Migration Step n
* Migration Execution & Validation
* Decommissioning of Replaced Resources
* Rollback Plan
Your migration plan should include going to each team in your organization and identify their processes, the custom solutions they use, the files they need and plan how and where you will migrate everything.
Let me be clear: none of the best bet articles I listed above explicitly say “No As-Is”.
Most experts agree, however, that doing a simple “lift and shift” is a bad idea.
Don’t simply copy the documents over “as-is”. Take the time to re-evaluate the Information Architecture to take advantage of the capabilities that SharePoint Online offers with Office 365.
Consider moving the sub-sites within sub-sites to a flatter site structure.
Consider using hubs to group sites together.
Consider distributing sub-folders to different document libraries.
Look for long file URLs and make sure that they’ll fit within the URL length limits once migrated.
Just make sure that you don’t accept the status quo.
Failed migrations often underestimate the effort involved in migrating content to Office 365.
To paraphrase George W. Bush, “don’t misunderestimate the effort involved”.
As Joanne Klein explains in her article, don’t underestimate the time it takes to plan the migration.
You also need to estimate the time you will need to migrate the files.
What’s the best way to estimate the migration effort? Perform test migrations with real files.
You can actually test the migration in your new Office 365 tenant. If you’re concerned about “tainting” your production environment, just migrate a site to a temporary destination in your production environment (e.g.: HR to HRTest) and delete the site after your tests are complete.
Once you have performed a test migration you can extrapolate the time it took to perform the test (including the time it took to do the analysis and planning) to get a better estimate.
As we discussed above (see No “As-Is”), you should not simply lift and shift your files.
Take this opportunity to clean up files as you go. Remove duplicates, remove old files and other files that have no business being moved to the new environment.
If your business folks have a “let’s keep files forever” retention policy, now is a great opportunity to encourage them to adopt an adequate retention policy.
While you’re at it, look for documents that have the words “Final” or “Draft” in them. Then look for documents with the same name — but without “Final” and “Draft” in them (they often have dates or version numbers in the file names as well). They usually indicate users who don’t quite understand how versioning works in SharePoint.
That’s also a sign that you should train your users.
With the number of training resources available out there, there are no excuses for not training your users.
The only valid reason for not training your users is if you want your migration to fail.
Take the time to create an Information Architecture for your migrated content.
If you don’t take the time to develop an Information Architecture that will help your users find the content they need, they’ll blame SharePoint for not being able to find documents and you’ll get poor user adoption.
If you need help with developing an Information Architecture, I’ve written a few articles on the subject — but there are plenty of resources out there.
“Be prepared to answer the question “how much of my time/my staff’s time will you need?”. Someone will ask.
Migrating SharePoint to Office 365 is more than just moving files and server resources. You need to change how your users will work too.
Don’t approach your migration as an IT-only initiative. It should not be.
Get executive buy-in, involve your stakeholders, involve your users.
The IT team can lead the migration initiative, but you need to involve other departments as well.
Consult the teams as you move their content and make sure that you listen to their pain points. Find a way to alleviate their pain points in Office 365.
As we said before, don’t forget that other departments also have jobs to do. They aren’t waiting at your beck and call. Be considerate of their time.
Be prepared to answer the question “how much of my time/my staff’s time will you need?”. Someone will ask.
Most experts will encourage you to test your migration.
By “testing”, we don’t mean counting how many files are in the source and — after migration — counting how many files are in the destination to see if it matches.
Before the real migration, perform a test migration with real documents to your real production environment and verifying that everything that was supposed to migrate did migrate.
After migration, get your content owners to test finding and opening documents.
Verify that you didn’t lose metadata when you migrated.
Verify that permissions are accurate and that users who shouldn’t see files won’t see those files.
Verify that those files with the longest URLs can be opened on a user’s workstation without any issues.
Along the same lines as Not just an IT initiative and Train Users, consider finding users who are willing to be your first test subjects.
They’ll become your champions later.
Don’t let some executive name their favorite people who don’t have any real experience using the old SharePoint site. Find actual users who are suffering so much that they’re willing to spend extra time testing the new platform, finding all warts and bugs — just for the possibility that the new platform will make their lives better.
Find those users who aren’t afraid to complain loudly, but who are willing to listen.
Find those who are influential among their peers. They’re the ones that will encourage other users to adopt your new platform.
Working with champions usually consists of three phases:
If you find that your users tell you that they don’t have time for you, that they’re too busy, it is probably because you didn’t try to find champions first.
Once your champions find how awesome Office 365 is, they’ll tell other users. Those users who were too busy and didn’t have time for you will soon be begging to work with you because they want to have all the cool stuff the champions got.
Every expert has their own perspective on what best practices exist when it comes to migrating SharePoint to Office 365, but there are common ideas that they all seem to agree with.
I would love to make this list even more comprehensive. If you have found an article that you believe should be included in this article, please let me know in the comments. I’ll keep growing the list and updating the research.