How to develop a SharePoint Online content migration plan & avoid costly mistakes

Many organisations are planning to move their workloads to Office 365, and as part of that, to use SharePoint Online as their collaboration platform. In the latest Collab365 Live Show, Andy Talbot and Nick Brattoli talk to Dux Raymond Sy (CTO, AvePoint) about how he approaches migration projects, and they review some of the tools and resources available.

When they first start thinking about a migration project, IT professionals may see selection of a migration tool as their first task, and this can seem daunting as a plethora of tools is available. Instead, Dux suggests that if they spend time researching and planning their migration approach, then selecting a tool will become the easy part.

Something that has changed significantly in recent years is the obligation organisations have to comply with data regulations. The Live Show discusses GDPR (General Data Protection Regulation), the new set of European data regulations, and how these, and other regulations, mean that your migration approach will definitely need to be compliant.

What Goes into a Compliant SharePoint Online Migration Plan?

At a high level, to enable an organisation to migrate, manage and protect their data, your plan should address these four phases:

Discovery and Analysis

First you’re going to need to look in detail at the data which needs to be migrated. According the data sources (SharePoint on-premises, file shares, document management systems, Notes …) there may be tools to automate some of this discovery process.

Regardless of whether you can automate discovery, you will also need to talk to business stakeholders about the content and shape of the data, and about their priorities for the migration. Allow a couple of weeks for this phase before you decide how to approach the technical part of the migration.

You need to produce:

• An inventory of the data items, including properties such as name size, date created and/or changed, file type, any metadata held.
• A list of processes, workflows, or rules that the organisation uses to manage the data.
• A list of “issues”:
  • Which files will fail to migrate because their path-name is too long or has illegal characters, or because they exceed the file size limit for SharePoint Online
  • Which data is aged and doesn’t need to be migrated?
  • Which code/processes do not need to be migrated?
  • Which customisation’s will/will not work in SharePoint Online?
  • Are there duplicate files? Are they exactly identical, or almost?

The tools available to help you include both free and commercial offerings, there are discovery tools from both Microsoft and AvePoint. Dux shared with the community a sample output, showing that the tools can mark which data will be migrated without a problem, and colour code data which has an issue:

Cleanse and Destroy

Next up is cleansing, which is partly about working down the snag list. But as well as looking at the data from the outside, it’s important to try to discover the contents of the data objects. Andy, Nick and Dux all have examples of private, or classified data which has been accidentally stored in a library which isn’t locked down. Try using search to look for things like:

• People’s salaries
• Disciplinary or performance appraisal details
• Keywords that are typically held in security classified documents

You will probably find some, I certainly have in my projects, and the organisation will thank you for finding it as early as possible!

It’s tempting to think that an IT professional should just make sure that “everything” in the source data stores is migrated, but organisations with a mature IT function almost certainly have some data that can be destroyed, and other data that can be archived. Just make sure you specify this in your SharePoint Online Migration Plan, as authorisation and sign-off of any data destruction is another part of compliance.

Tag and Classify

You may have the opportunity, dependent on which tools you are using, to apply metadata tags as you carry out a migration. As well as listing the data items, your discovery should have given you an idea of the data taxonomy.

You’re not trying to invent a complete Information Architecture, but simple steps can help later on. Andy suggests adding a Content Type inherited from Document (e.g. “ABC Company Document”) and adding a single classification field, so that you can tag sections of the data where it’s helpful, for example, where data is private or confidential.

Secure and Migrate

Make sure that your plan specifies what data is going to need to be secured. You will need to look for, and plan how to handle:

• Regulated data: which needs long term archiving to comply with laws and standards: for example, financial data
• Sensitive data: which might relate to employees, customers, or citizens
• Classified data: which can include military type security, as well as intellectual property

Your discovery work and business stakeholder discussions should have helped you to decide what phases or sections to divide in the migration into. Some sections of the business will be sensitive to the time of the year, or of the month, and downtime will always be an issue.

To get a better idea of actual transfer times, once you have a technical tool, put a pilot phase into your plan, to get early site of timings, and snags that are likely to arise.

Lastly, before you start your full migration, record your expected times, phases and the resources needed in a formal plan. The resources section of this article includes a “starter for 10 plan”.

Enable and Connect

After all that planning, you can connect up and start the migration! Don’t forget to plan a UAT (User Acceptance Testing) activity, possibly for each phase, structuring this in advance will help you to measure success later.

You also need to plan for adoption. This usually takes longer than expected (the panel think an average of 18 months). A good tip is to record all the snags that arise, and use them to form frequently asked questions that you can publish periodically.

Integrate and Automate

In a nutshell, what is needed to retain compliance in the newly migrated world, is to make it as easy as possible for users to follow the agreed data handling procedures. Can you automate anything? Or simply provide defaults for some of the metadata fields. Microsoft has some new tools (see below) which can help you here, so make sure you are aware of the possibilities.

Record, Archive and Dispose

What about the “run phase” of the migrated site? It’s essential in the newly cleansed and migrated estate to “keep it clean”, and you have several weapons here. As well as standard information policies and workflows, Microsoft has invested heavily in the Office 365 Compliance Center and Azure Information Protection. There are a host of features which take some degree of responsibility away from users, and allow document life cycle policies, and protection rules, to be enforced.

Any time you spend ascertaining and discussing the organisation’s policies will help you to apply these tools, and also make compliance easier (and more automatic) for end users.

9 tips for SharePoint Migration Ninjas

1. Take the time to develop a plan! It’s going to pay off by easing the process of tool selection, enabling you to establish regulatory compliance, and helping you to establish stakeholder expectations
2. There is going to be some sensitive data which might relate to employees, customers, or citizens, but it might not be in the right place, or secured correctly. Use search to try and locate anything like this.
3. Carry out a pilot – take a cross-section, see how it worked, and tweak the plan accordingly
4. Don’t have an Information Architecture? To be stay compliant, you’re going to have to agree at least the basic document handling and lifecycle rules with the business, and then make this as easy as possible to achieve for end users.
5. Have a defined UAT – designing it will help to establish customer expectations, carrying it out will surface any snags, and later it will help to express project success
6. Adoption isn’t automatic, and takes time. Establish a support mechanism, and publish FAQ’s regularly. The Live Show panel like using Visual SP as a support resource.
7. Sprints aren’t just for coding projects, it can be a good idea to organise your whole migration project using a SCRUM-like methodology.
8. Try to keep old document management systems accessible, but read-only, for six months, but it’s probably best not to advertise this widely until they are really needed to answer queries.
9. Make a positive effort to establish success: you can use comparison tools, interviews, usage surveys. We tend to think in terms of Office 365/SharePoint technical features, enabling them one at a time, but why not phase by business-centric experiences instead. By delivering a particular experience you will add value, and will help to establish the success of the project.

This article summarizes Collab365 Live Show #6.

Dux has kindly made his Slide Deck from the live show available for the community: