Introduction

Recently, I’ve seen a few questions flying about on the various SharePoint community Yammer networks, forums and LinkedIn groups about migration. I thought I’d weigh in with my usual approach to migrating content into SharePoint, which will hopefully help you to facilitate a smooth, successful, on-time, on-budget migration project.

Analysis of source data

Before you can think about what tooling to use, how you’re going to communicate the migration, or any other activities, you need to know what it is that must be moved. Your analysis of the source data should include the following information to help you make sensible, informed decisions later in the migration process:

• What is the total size of data?
• How many files must be moved?
• How frequently read is the info?
• How frequently updated is the info?
• When was the last time the info was read?
• When was the last time the info was updated?
• What types of files exist?
• What is the average size of file?
• Are there any specific permissions applied?
• How is the data apportioned into different ‘buckets’ within the source system?
• Who is the owner of this information?
• Are there any unique IDs that need to be migrated?
• Do old versions need to be migrated?
• Are all users of the old system in SharePoint (user mapping)?

This analysis piece will likely take the form of some analytics stats, perhaps presented in a graph to help make sense of it, plus an extract in .xlsx or .csv format that captures the granular detail about individual files.

If your source system is SharePoint…

If your source data is stored in SharePoint, there is some additional analysis you will need to do in order to prepare for a migration:

• Are there any full-trust code solutions on the system?
• What is the database count?
• What is the site collection count?
• Are there any unghosted files?
• Are there any custom site definitions?
• Are there any lists with a large (>100k) number of items?

A good tool to use to gather this information is AvePoint’s Discovery Tool.

Prioritisation of source data

Using your analysis, you need to make some high-level decisions about what is going to be migrated. Key things to keep in mind are that if you are migrating to a comms publishing portal (intranet), then you probably don’t want to take working documents over – you only need published content. Based on usage stats, you can also start to formulate a plan in terms of which are the big ticket items that must be moved, which are the quick wins, which areas can wait a while, and which content is not worth migrating at all. This is also the time to start involving the business in some of the decision making. I find a workshop where the analysis is presented and discussed works well, and it sets the wheels in motion ready for the ‘Housekeeping’ activities (see below).

If you’re migrating from SharePoint, this is also the time you need to start worrying about full-trust code (server side code). If you’re migrating to O365, you will have no option but to rebuild these solutions as provider-hosted apps. Even if you’re migrating to an on-premises SharePoint environment, you should still consider following best practice and rebuilding any full-trust solutions as apps.

Housekeeping

The big thing to avoid with migration projects is moving rubbish from one bucket into a newer, shinier bucket. A migration is your chance to clean up some of your content and ensure your new system is better used and more organised. You need to engage the business and empower the content owners of each logical area to remove, change or add any information they feel they should. Buy in from senior stakeholders within the business is essential for this process, because people are never very motivated to do any housekeeping unless their boss is breathing down their neck making them do it.

Target system information architecture

If you’re moving content to a ‘greenfield’ SharePoint environment (i.e. one that is brand new and isn’t currently being used), you have the luxury of being able to design your information architecture from scratch. In SharePoint terms, information architecture is how your site collections, sites, libraries, lists, and folders are structured; how to classify information (metadata and content types); how to secure information (permissions); how navigation works; and how search works. If you’re starting with a blank slate, you can design your IA with the migrated data in mind, in order to make the migration process as easy as possible. A few things to keep in mind when designing your IA are:

• Content size boundaries (such as the 200Gb content database size limit for SP2013 on-prem);
• The list view threshold (5000 items);
• The lookup threshold (8 columns); and
• Avoiding item-level permissions.

If you’re migrating into a ‘brownfield’ SharePoint environment (a pre-existing, already-used system with live content and users), things tend to become a lot more difficult. You might have to refactor some of your original IA in order to accommodate your new content while still ensuring the system is scalable and does not exceed any defined size boundaries.

Something to avoid – particularly when migrating from file shares – is simply replicating the source system folder structure. Though folders aren’t necessarily an evil thing in SharePoint (as some consultants might lead you to believe), you are still likely to face issues around usability and maximum URL characters (256) caused by deeply nested folder structures. A flatter, metadata-driven structure is often a better alternative, though it takes more work to plan out.

Mapping and categorisation

You will need some way of knowing where content from the source system should land in the new system, and how it should be profiled with metadata. It’s important to do a mapping exercise to define this. You can define mapping for buckets of content, specifying the location they should be moved to in your new system, and you can do some categorisation on an item by item basis to provide any metadata that will be required for the migration. If you’re building some sort of custom tool or script to move your content, this step is especially important: You need to be prescriptive about precisely where each item needs to be moved when you are scripting the process.

Select the right tool for the job

There are several third party migration tools available from the likes of AvePoint, Metalogix and ShareGate. Personally, I have used Metalogix and AvePoint tools and found them to be more than adequate. I’ve not used ShareGate yet myself, but everyone I’ve spoken to about it has sung its praises. Therefore it probably comes down to your project’s budget and your organisation/implementer’s existing partnerships which tool you select. I suggest you assess all three of these tools. If you’re moving from SharePoint to SharePoint, a third party tool is almost always the way to go, at least in my experience.

An alternative to using a third party product is to build your own tool, or write a custom script. This is often a cheaper alternative to buying a product, and can often be the best option if you’re doing a relatively low complexity migration, for example from a file share into SharePoint. The thing to keep in mind is that your mapping logic will need to be sound, and you will probably need a complete extract of all the source data.

The final option is to get users to migrate content manually. I find this is a good choice if you have lots of rubbish in your source system that needs serious housekeeping: if your business people are migrating content themselves, they are inherently more motivated to do some proper housekeeping by virtue of the fact they will be reducing their own workload when they come to actually move the files. It is also a solid option for web pages if you have defined some nice new layouts in your target system, but still need to take across page content (particularly true of content stored in Content Editor Web Parts on SP2010 and MOSS 2007).

Trial run

Before migrating into your production environment, it’s worth doing a trial run into your pre-PROD or User Acceptance Testing environment (you’ve got a UAT environment, right?). You can test your mapping logic, tooling, and – perhaps most importantly – get a good idea for how long the process will take. This information will allow you to plan downtime, change freezes etc. more accurately, and ensure you can set the expectations of your stakeholders correctly.

Testing

You need a plan for verifying a) that the content has all been moved, and b) it’s in the right place with the right metadata in your target system. Another key thing to test for is broken links, which will almost certainly be a problem if you’re migrating any pages. Users and content authors don’t tend to understand the concept of relative URLs, so it’s likely any links between pages on your old system will be broken post-migration.

The actual migration

You need a solid plan in place for the actual migration into live, and you may need to communicate/enforce a change freeze in the source environment. An alternative to a change freeze is to migrate, get your users on the new system and then go back and ‘mop up’ the delta between your first migration and the go-live on the new system. A good time to do migrations is usually over a weekend, since they often cause disruption (either through change freezes or ‘locks’/performance problems when extracting or importing data).

Change Management

From the outset of the migration project, you will need a solid communication plan in place. You need to tell your stakeholders what will be expected of them and when, plus informing any users of the source system what is going on. You need to explain to users why the migration is happening, when it is happening, and anything they need to do (or not do).

You will also need to train your users with the new system: content authors will need to know how to create/edit/publish pages; users will need to know how to upload documents, categorise information and navigate the system; and site admins will need to know how to add new libraries, folders etc. The type of system you are migrating from should also impact how much training you need to do (for example, migrating from MOSS 2007 to SP2013 won’t be a massive step-change, but going from an ancient file share to an all-singing, all-dancing SharePoint system will be a major shock to the system for your users).

Governance

One final thing: if you don’t want your new system to descend into chaos, you will need a well-defined, enforced governance plan in place. Governance is a big topic, so I won’t open that particular can of worms here, but it’s something you need to ensure you have in place in order to realise many of the benefits of migrating to SharePoint in the first place.

Bringing It All Together

So that concludes my whistle-stop tour of how to approach a migration project with SharePoint. The complexity of migration should not be underestimated, and it is rarely a case of a seamless “lift and shift”. Even for simple migrations, there is a lot of analysis, stakeholder engagement and planning that you need to do in order to ensure success.

Thanks for reading.