Written by Michelle Bolda, Rogue Services and Solutions.

Over here in Rogue land, we have managed many migration projects. Some have been for large enterprises, and some have been for 6MB of data. Most of our clients are upgrading to SharePoint Online (aka “migrating to the Cloud“).

A question we get a lot is, “Can you just move it over during the upgrade, and then we’ll take care of cleaning it up?” I’m going to be blunt here: No. That’s always a bad idea.

I’ve lived in several houses in my life, which means I’ve moved a bunch of times. Each time I think it would be so much easier to take the dozen or so things I really care about and then burn everything else to the ground rather than move it. That’s how I like to approach migrations.

If you “lift and shift”–that is move everything from where it has been to your upgraded SharePoint environment, it’s like taking everything from your current house and sticking it right where it is in the new house. But your new house is different… the floor plan is different, the walls are in different places. And you probably don’t need everything you had in the old house. Lots of people end up with piles of trash to the road when they’re moving, and for good reason. You also may need new/different stuff for the new house. We should look at a SharePoint upgrade and migration in a similar way.

At Rogue, we follow a formula for migrations, and it has been successful for us. Want details? Yay because that’s why I’m here.

First, we run a script on your environment to determine how much data you have, what types, when it was last updated, etc. At a high level, these analytics help to guide our clients in determining what they can leave behind. You don’t literally have to burn everything to the ground here, unless it’s cathartic, and then we won’t stop you. Most of our clients archive the stuff they really don’t need. Sometimes that means putting it on a tape and sticking it in a drawer. If you want to keep data “just in case,” there are many ways to achieve that, though we always recommend taking a hard look at what you need and why. Information hoarding just because is a habit a lot of us have gotten into but probably isn’t really necessary to run your business.

An upgrade should benefit you in several ways, and one of them is to rein in content sprawl and disorganization. Keep relevance top of mind. Also think about how the information should be presented (maybe a list of events should actually be presented in a calendar web part?) and where it should live (which site).  That’s why, after our script analysis, we work with specific business owners, the content authors and key stakeholders, who will be affected by the migration. We go through the data and make the keep, delete, or archive decisions; plan where that”keep” data should live based on the information architecture of the upgraded environment; and decide how that information should be surfaced in the new world of SharePoint (list, library, workflow). There is a lot of coordination with our project sponsor so they understand the decisions of the business owners.

We also dig deep into any custom SharePoint development. Sometimes custom functionality is unfriendly during a migration–meaning it will break, and how. We figure out a way to modify or re-develop it so it will work in the upgrade or, depending on the amount of customization, recommend a hybrid model. We’re not going to get into hybrids in this blog post. I will save that tasty morsel for later.

Once we have a good list of data to keep, where it should go, and what format it should be in, we do what my partners call a “test migration iteration.” That’s a lot of -ions, but they are good ones. This is a test migration that helps us determine fail points. We keep a log of problems, fix them, and then know what to anticipate for the big show, the production migration. It also helps us to know how long the migration will take.

We schedule the migration timeline carefully. In active SharePoint environments, you don’t want users rendered unproductive and be super ticked off that no one told them they wouldn’t be able to get to their stuff. Over-communication is incredibly important at this point. Make sure everyone in the organization knows that SharePoint will be down, starting and ending when, so they can save their work instead of getting a nasty surprise when they hit the environment to access their most needed documents.

Here’s a surprise: We actually migrate ALL the data via a third-party migration tool and then use scripts to clean it up based on the keep/archive/delete decisions. We do this so that we don’t accidentally leave “keep” data over in the old SharePoint universe. It’s also much harder to pick and choose pre-migration than it is for us to clean it up post-migration. The point is we clean it up automagically (or, ok, with scripts) so that it’s not mistake prone. We find that when clients have tried to “clean up” after a migration, the manual work creates problems, and they also lose the benefit of recasting that list of events as a calendar web part, for example.

We plan migrations over nights, weekends, and holidays. Doesn’t that sound like a job perk? Sarcasm. But it is what works well for our clients, so we do it. We also ask those business owners to test in the production environment, by Sunday evening for a weekend migration, so that we can ensure all our troubleshooting and fixes were on point. Then we remediate until the sun comes up if that’s what it takes. During remediation, there is a lot of contact with the project sponsor and any business owners who have issues during their production testing.

[Original Post: Why Lift and Shift Never Works and Other SharePoint Migration Truths]

Interested in learning more? Attend the Digital Workplace and Intranet Summit in Washington, DC, October 23-25.