There is no Good Way to do a SharePoint Migration

I do a lot of SharePoint migrations. Possibly, more than I care for. In fact, while I don’t often talk about them, I’ve written about them in the distant past before the end times. Check out my 2015 blog post “3 Keys for Managing a Migration Project” if you’re like me and like any excuse to go down rabbit holes. I’ve learned a lot from those migrations and the biggest takeaway is that there is no good way to do a SharePoint migration! There are many ways to tackle a migration and I do have my preferred method but there’s no one size fits all approach. In this post, I’ll rant talk about a couple of migration approaches and the different ways they’ll accelerate your aging process. Before I continue, I’d like to point out that I’ll be focusing on moving to SharePoint Online and not covering specifics about on-prem and DB attach scenarios.

Approach One: The Big Bang

Generally, I’ve used 2 different approaches. The first and most common is a phased, somewhat big bang approach. This approach is the easiest on the migration team. The general idea is that you migrate everything, using your migration tool of choice, right up front so you can stage the content and fix issues before doing a 2nd pass that will pick up new or updated content. The benefit of this approach is that you can run your migrations and as the individual sites or site collections are fully migrated, you can start fixing any issues found in those sites while the other migrations are running. This allows the team to take their time and refine their process as they make corrections. It also allows you to operate with a smaller team because you will have weeks/months to find and fix issues.

Another benefit to this approach is that it gives the business time to take a look at their new sites and look for issues – the user acceptance testing. This sounds good, right? So what’s the problem? Well, this approach depends on how your customers are using SharePoint. In other words, are they active/savvy users who understand “best practices” when it comes to content management, information architecture, collaboration, etc? Are they on top of their security? Do they constantly adjust their permissions? Do they use retention polices or remove unnecessary content? If this is the case, then the big bang approach may not be the best option. Why? you ask. Well, migration tools move content from point A to point B but if content was removed from point A after it was already moved to point B, you will have unwanted content in the destination.

Let’s say we have a scenario where a customer does a huge content purge after you’ve done your first pass. When you do your final migration, you’ll see that all the deleted content is in the destination. The tool will not delete that content from the destination once it has been migrated. (No matter how many times you tell people and no matter how many emails get sent to them, there is always someone who ignores it and deletes a ridiculous amount of content that has been sitting in their library for a decade. That day that they decide to do their first ever content cleanup will be the day before your migration cutover.) A similar issue involves permissions. Specifically, the removal of someone’s access. Again, you could end up with people having access to content that they should no longer have access to.

Follow instructions, people!

Despite the fact that SharePoint is old enough to drink, many, many, many businesses do not have a mature environment and often use it as a dumping ground for content. (Oh if they knew all the wonderful things it could do). That “immature” usage and fairly static content or content that is almost exclusively adds vs deletes makes this approach a good one but it’s hard to know for sure if this is the right choice. The larger the org, the harder it is to determine this because some site owners may make the best of their tools while others see it as a folder.

SharePoint Maturity

Approach Two: Fast and Furious

An alternative approach to the big bang is what I’ll call the fast and furious approach. (Just so you know, I don’t use these oddball names in real life.) This is when you don’t have a lot of time to fix things and your primary focus is the content. You’re just dumping as much as you can into the destination and only addressing major or obvious problems. In this scenario, you don’t care about broken links or images. (I mean, you kind of care, you just don’t have much time to find and address them all.) You just care that the data was moved. This approach usually has a short window between the initial pass and the final cutover and it gives the business a smaller window to make major changes. That one person will still wait until the day before the cutover to delete a bunch of stuff so you still have that issue to contend with but it should happen less often.

Fast and Furious Approach: Just Move it all!

So what’s the problem with this approach? Well, for starters, you don’t really eliminate the drawbacks of the big bang approach; namely, people removing things after the approved window. It shortens the timeline so you have to eliminate some of your cleanup efforts because you simply don’t have the time. If you happen to live by the ‘make things better than you left it’ motto, well, you can almost forget about it in this scenario.

The biggest, hairiest, ugliest issue that this approach has and the thing that the big bang approach solves, involves replacing custom solutions. If you have any web parts, event receivers, timer jobs, InfoPath forms, Nintex forms, Nintex workflows, SharePoint Designer Workflows, workflows created with Visual Studio, or any other custom stuff out there in volume that aren’t getting scrapped, you have essentially committed to burning out your team.

Hey, you have a week to rebuild a solution that took years of refinement

In this approach, you absolutely need to get your solutions rebuilt first and they have to be far ahead of the migration schedule. But this is where the vicious cycle begins because in order to build those solutions, you often need the sites/lists/libraries that support those solutions so you need to have a migration run so the team can build against the correct data, but now you have sites that are out there partially migrated while changes are happening in the source. If you have a lot of solutions to rebuild, strap in for the ride because understanding the complexities of all the solutions, finding someone in the business who uses the tool and knows the nuances, and getting them to test in an accelerated schedule is almost impossible. So what will likely happen is that proper testing will not happen, sites and solutions will go live, and weeks/months later, the bugs will start coming in while you’re still trying to crush the next batch of solutions that need to be rebuilt. That description sounded chaotic…. well, so is the process of building things at that pace. You have to accept that things will not be perfect and understand that issues will come later. You also need to hope that the major issues don’t occur in the critical solutions.

Woosaaahhh. This approach is manageable if you have next to no custom solutions that need to be rebuilt. If you’re deciding on big bang or fast and furious for the same project, assume double or triple the team size for the latter. Maybe buy something nice for the people rebuilding the solutions. They deserve it.

Too much work, not enough time.

Tips and Tricks

Whichever nightmarish scenario you find yourself in, there are things you can do to make things as easy as possible. For one, automate what you can. Some may go ahead and use the migration tool clients and manually select source and destination but when you are working at scale, scripting that will reduce mistakes and speed up the process. In terms of the content migration, you still have technology limitations and throttling to work around so it’s not as simple as adding on another body to push more data. In fact, adding more people and running more migrations could potentially worsen the problem because if you get throttled, your jobs will see a reduction in speed.

Automate things that commonly break. Automate some of the comparison work that you have to do. Just automate whatever you can. If it takes something away from the team’s list of tasks or gives them one less thing to think about, automate it. Start with the most time consuming or complex items and build as you go.

Something that I recommend is that you create an Standard Operating Procedures library to help guide the team. The most recent large project that I was involved in required around 8 people just on the content migration side. Every time we identified a task or issue, we took the time to document in simple terms an SOP for it. The SOP template included:

• Title
• Purpose of the SOP
• Steps (this was written in very simple terms and literally started each line with Step 1, Step 2, Step 3, and so on)
• FAQs (anytime a member of the team asked a question related to that set of steps, someone would go in and add the question and answer)

The SOPs were probably the most important thing that drove the success of the project. If not the project, my sanity, because one of the things I can’t stand is repeating myself. Once the library was created, if the question came up again, everyone was directed to the SOP library. The team was empowered to add to the library if they felt something was missing. They also were encouraged to add to an existing SOP’s FAQ section if they had any questions related to the SOP so that we could avoid having new members ask the same questions.

Conclusion

Migrations are not all doom and gloom. There just isn’t a perfect way to run a migration and your approach will depend on which issues you can live with the most. (Did I just repeat myself?). You have to determine what is an acceptable turnaround time for a site’s migration and how much extra work is involved once the data is moved. From there, you can start deciding on which option to go with. Big bang is more relaxed and cost effective because the team size isn’t as large but you have more time between initial and cutover for things to go awry. Fast and Furious is… well… fast and furious. If you are only moving content, this is manageable but if things need to be rebuilt, especially in mass, then find out what the team’s favorite drink of choice is before the project starts and periodically send them a bottle. But drink responsibly.