Three Decision Maker Tech Tips For Your SharePoint Migration

TLDR - Use, but don't rely on, a specialist tool; Automate for repeatability and consistency; Continuous improvement. 

MS Teams and SharePoint have built-in capabilities to copy and move content around your tenancy. They are designed as end-user capabilities to move small qualities of data around. They are not ideally suited to address the challenges of moving medium to large quantities of content, especially between Site Collections. When doing a migration of content, even a few thousand documents, their lack of traceability and inability to recover from errors can become problematic and for large migrations they are, in my opinion, a showstopper.

So what approach would I suggest instead? Well, the obvious answer is to use a specialist tool like Sharegate etc, but even these are not the whole answer. So below, are 3 tech suggestions for migrations using specialist tooling.

Don't 100% rely on your specialist tool

Ok, great, you have a specialist tool to do the job. You might think this is the end of the story, but from my experience, I'd recommend that you only trust it as far as you can throw as the (UK) saying goes. This might sound like I'm being critical of these tools, but the reality is every piece of software ever written has bugs in it and I suspect that will always be the case. Also, as bugs get fixed, or new features are added, or "improvements" are made, more bugs sneak in. I would not want to say to one of my clients, yes, I know we lost/corrupted your files as part of this migration, but it was because we had absolute trust in XYZ piece of software.

So what to do instead? I would suggest you mitigate the risk by complementing your tool's built-in error reporting by either buying or writing your own verification tools. My preference is the latter. In particular, as my colleagues and I have done in the past, write one that uses your migration mappings and what is actually in the source and destination and checks every version of every file to ensure everything that should have been migrated has been. This all adds time and complexity to your migration project, but I assure you, it's worth the cost.

Automate for repeatability and consistency

I make mistakes. I probably make more mistakes than I realise. I suspect most of us do, some more than others I grant you, but we all make mistakes, especially when it comes to repeating the same tasks over and again. The sort of repeating you might do during a migration.

One way I've found of mitigating the risk of mistakes is to automate. Tested and debugged automation is much more likely to produce consistent results, improve accuracy and in the long run, when taking addressing issues into account, improve the overall time of the migration.

Ideally the automation should be programmatic, so once you have defined where you are migrating to and from, the actual migration(s) happens at the touch of a button. Does your specialist tooling allow for automation? If it doesn't, or only allows automation using its built-in routines then I'd suggest a double check to verify that it is the right tooling for you. It might be, but if the automation is not under your control and allows you to use the what you feel are most appropriate automation tools for your scenario and environment, then you are adding risk, or in the worst case in a controlled production environment, your migration solution may not get through your IT governance processes.

Obviously there is a cost to automation and for a small migration the benefit may not outweigh the cost. But even in this circumstance, I'd suggest manual automation. i.e. have a defined process, broken down into steps that must be followed, along with a confirmation of each step's outcome. In terms of confirmation, I'd avoid tick boxes. Instead perhaps use a combination of date/time, signature and comment (maybe a screen shot of the outcome of the step is the comment).

Apply a continuous improvement approach

Ok, more self-confession time. I don't always get it right at my first attempt. Actually, I'd have been better off not adding the suffix "at my first attempt" to that sentence! The chances are though, that you'll not get things 100% right the first time either, so my suggestion, even if your desk review and field testing of your process seems ok, please still incorporate continuous improvement into your processes.

How should you go about this? 

I'd suggest things like getting feedback from users, measuring your success/fail rate on actual migrations, do regular reviews, test edge cases as you start to better understand the data you are migrating, have open forum retrospectives where all voices can be heard etc.

There is no rocket science here. It's just a matter of regularly challenging your assumptions and taking a (constructively) critical look at what is actually happening on your migrations. It might seem an overhead at times and you might have many retrospective workshops where no improvements are found. But this is no reason to stop them. When they do uncover things, you'll thank me, or better still, please thank the person who found the issue! 

As always, thanks for finding the time to read this far, regards Chris.

About the author: Chris is a Delivery Manager, Technical/Information Architect. He works for Triad Group Plc in the United Kingdom