The most common scenario we see in the market today are organizations that still rely on paper, network file storage and emails (so don’t worry, you’re not alone) for their organization’s content management. After deciding to standardize on a platform like SharePoint for ECM, one of the biggest and most critical tasks is performing the migration of content into the system. While scripts and tools should certainly play a role in a migration strategy, we will try and persuade you in this blog that, perhaps somewhat counter-intuitively, manual migration may be the key to a successful ECM implementation.

So after requirements, analysis, design, configuration, review, and refinement of a group’s collaborative SharePoint solution comes time to start our migration. In general, we want all the current working, operational and otherwise important content to end up in our new solution. This will help drive adoption and allow us to start meeting our needs around compliance with either Microsoft 365 compliance or Collabspace.

This typically means we’re migrating a year or two’s worth of content into the system. People are often, with good reason, a little scared of the daunting task of migrating large volumes of content into the new system. Projects often then turn to tools or scripts to automate the process. While I grant that tools and scripts should play a part of a migration strategy, we’re going to make the case here that manual migration should be a part of your all up-migration process and that doing so is critical for the all up adoption of the new shiny, new ECM platform.

It’s no surprise these days that adoption by end users of our system is the biggest hurdle that any ECM program faces. Anything we can do to improve adoption will drive usage, maximize ROI and enable us to meet our records management needs around compliance.

Migration parties

Migration Parties, as we’ve termed them, are sessions held with the entire project team coupled with the currently engaged group to migrate their content into SharePoint. Ideally, we’re sitting side by side, coaching end users, helping with some of the migration, answering questions, making refinements, and taking notes on any points of friction that we observe.

In practice, with SharePoint’s quick edit, drag and drop, explorer view and default values, migrating 1000’s of documents in a couple of hours is actually pretty easy. In fact, more often than not when the team builds momentum, we often get asked to extend the migrations sessions as, say, for example, they only have one more month of invoices to migrate over into the new system.

We will, of course, leverage scripts and tools for more historical content, but depending on the nature of the project, it’s likely not critical to have this done for go-live and can be done by a spare team in the background post go-live.

The main benefits of manual migration parties are:

IT reinforces training and solidify skills

End users will likely and hopefully have had several hours, if not days of training on in SharePoint, perhaps on the solution itself or some generic SharePoint training. Unfortunately, most people forget 70% of what they learn within 24 hours and 90% of what they learn within a week. It is, of course, critical to the success of our ECM platform that end users are as comfortable as possible with SharePoint for us to drive adoption. Any opportunity to reinforce training will only be to our benefit, and what better way than to have end users upload 1000’s and 1000’s of documents over a couple of days?

They’ll know exactly where their content is located

Have you ever experienced the frustration after someone rearranges your kitchen or been trying to find a spoon in someone else’s?  One of the complaints we hear from end users if their content is migrated for them is that they forget where the content is (yes, they could use search) but nevertheless, it’s a point of frustration that introduces risk around garnering the level of adoption that we’re trying to achieve.  The number of these types of complaints is significantly less, near almost zero, if the group manually migrated all their current and important content, regardless if the team was there for the requirements, design, and configuration.

You’ll identify and fix problems earlier

Regardless of all the reviewing and refinements that go into a well run agile ECM project, it’s typically not until end users are uploading 100’s of real world documents do they gain an appreciate for the finer details of how the solution should be set up. For example, they may have thought they wanted to capture the invoice amount, but after uploading a couple of dozen documents do they realize that stopping to open the PDF, hunt for the invoice amount and cutting and pasting into SharePoint just isn’t worth the hassle, not to mention if an invoice amount was in question, they’d likely be opening the actual invoice anyhow. Sitting side by side with end users to support them in their migration is the most efficient way to identify these small tweaks required and helps end users understand that the solution is, in fact, malleable, often we’ll change content types, create views, or restructure content right in the middle of the meeting to help smooth out the points of friction from the solution. The earlier we identify problems and address them, the happier our users are and we’ll minimize the overall effort\cost.

You’ll build trust and solidify relationships

We call them migration parties for a reason. We’ll bring treats, have lunch, and sometimes grab social drinks with everyone after a hard day of migration. Thinking about just how intimate ECM projects are (in that nearly everyone will need to use it every day), it’s critical for the project team to build a trusted relationship with each of the groups being brought into the solution. It’s this trust and the hopefully affable relationship between the project team and current group that will help you through some of the tougher conversations, low points, and stressful situations. Like any properly functioning relationship, it’ll take good intentions, hard work, compromise and, of course, food.

Doing migration parties remotely with Microsoft Teams

Recently, we were wrapping up work with a client in the education space before COVID-19 hit. We had almost finished their SharePoint Online (SPO) rollout when things escalated to the point where everyone had to work from home.

This happened at a critical time for the project. We had planned key activities, including migration, for the last couple of weeks of the project. The Director of HR messaged me the week before a scheduled activity — the migration party — to share that they were no longer going to be coming into the office, and that all remaining meetings are to be via Teams. For the remaining training and migration planning sessions, I was not concerned about facilitating them remotely. But for the migration party we had scheduled, I worried about having to engage people remotely.

Why we recommend in-person migration parties

Before the pandemic and having to work solely from home, I would have told you that migration parties are hands-down one of the most important sessions to do in-person, so that the users who are migrating can have as much face-to-face support from their implementation team as possible. Now being faced with not supporting my team in a face-to-face/hands-on capacity, I was nervous that there would be silence on the line, or that people would stay quiet instead of asking for help, which would all ultimately lead to lower adoption of the new solution we had spent months preparing together.

The purpose of hosting migration parties is to support users in migrating content from previous location(s) to the newly developed ECM platform. This is a great way to reinforce training, and for users to get to know the new platform intimately and familiarize themselves with where content is now stored. This is also a celebration of all the work they have done, with perhaps food and drinks, and maybe even making it a potluck for fun.

I was super conflicted! Can we even do this one remotely?

How to do an online migration party

I knew that pausing this rollout was not going to be a viable option, so I had to get creative with how I facilitated and talk A LOT during the 2-hour session. To my surprise. this session ended up being one of my best migration parties to date!

Here is what we ended up doing:

1. CONNECTING: We all turned our CAMERAS ON and joined the Teams meeting. We took some time to catch up on the latest happenings in the world and took the opportunity to say hi and reconnect after a while of not seeing each other.

2. TRAINING: We then ran through our Migration Readiness presentation deck and went over all the “Do’s and Don’ts” of migrating content into SPO to reiterate the training they’d all been through.

3. PLANNING: We opened and reviewed the Migration Planning spreadsheet that we filled out together the week prior, to make sure everyone was super clear on who was moving what from their File drive into the new site.

4. MIGRATING: The team got started! Due to our diligent planning and preparation, there was no question of who was moving what, or where things were going. As soon as the “migration” portion of the migration party began, the team was moving things into the solution at lightning speed and it was awesome!

5. SCREEN SHARING: As soon as anyone had a question or needed help with something, I asked that they screen share so that the rest of the team knew exactly what they were talking about (and also so everyone could visually see what it is their team member was experiencing). Once they posed their question, I would then screen share how to do the thing they were wondering about, and then pass it back to them to complete the task (AKA I didn’t do it for them). Without doing it for them, the team was able to go in and immediately apply the knowledge they had just learned (or in some cases, forgotten) and the rest of the team was on the same page with what was happening.

6. AUDITING: Throughout the session, I constantly clicked around the site to audit the uploads of the team members to make sure that everyone was uploading their content correctly and not simply “lifting and shifting” content into the new site. If there were users who uploaded things “incorrectly” (e.g. uploaded folders for each year as opposed to uploading just the files and tagging the year instead), I would (respectfully, of course!) get their attention and walk the team through the better/more valuable way of uploading the content. In this way, it was perhaps the most transparent and vulnerable migration party I’ve ever run! We were all in it together and open with one another about any confusion or getting extra help when needed. I firmly believe the whole team learned a lot from one another.

7. COMMUNICATING: Of course, when dealing with people, we know some are more vocal or comfortable speaking than others. So, it was super important to constantly ask how each person was doing, especially if they were quiet. I noticed that quieter people had questions that they might not have asked if not prompted. Encouraging open communication was a huge factor of the success we experienced in this session.

Lessons Learned

Doing the migration party in Teams was almost better than in-person. Often, during in-person migration parties when individuals have questions, the rest of the team usually continues to focus on their own computers instead of getting involved when someone else on their team needs help or has a question. An online migration party was an awesome way to get everyone involved in learning and growing their SharePoint knowledge, all while uploading more and more of their content into the site! 

So a little manual migration can go a long way. You’ll end up with a working, refined and highly adopted ECM solution.

Do you need specific help with migration or moving to SharePoint? Reach out for advice.