MIGRATION: DIY OR GET A PROFESSIONAL?
Author: Jonathan Stuckey
Audience: Technical consultant, Solution designer, Information manager, Project manager.
Tackling content migration
Today we had the philosophical discussion in the team, about what and how much do we give away to people with our offerings, the skills, scripts and tools. Specifically, we were talking about tools for content and data-migrations as we (re)draft our submission to the local government marketplace.
My colleagues raised a point that telling people what tools we use and why we use them is fuelling an “DIY” approach to migrations by organisations who think it will save on costs - but it doesn't. We get far too many calls from customers who've suffered from the 'cut-n-paste' of file-server to a library or an attempt to replicate legacy SharePoint farm to SharePoint Online in 'lift-n-shift' of site-collection to worry about an in-house techie getting up to speed.
I personally don’t believe telling people that "good tools exist" and "we use them", is a problem. If your organisation only wanted what they've had for 10years copied somewhere else verbatim they can DIY - but the poor-old techie driving the tools is in for a real kicking not that far down the road when it doesn't produce the 'miracle' benefits the business was promised.
Yes, a smart-person could look up the tool(s) we use, read the providers content, watch the videos on the vendors site and think they know how to deliver a project using them.
Yes, a person who’s been involved in a previous project that had elements of data and content migration can apply some experiences to the outcomes and get results.
Yes, a bunch of organisations will try to DIY their migration, and some will do a good job... (usually when business requirement is simple to deal with and no one is paying attention to those pesky regulations which say you need to manage your content properly - wherever it is).
I’m a smart person; this is what I did 15+ years ago. Then I went and did practical projects with real migrations, in a range of client environments and boy did I learn some hard lessons.
You see a tool that copies-n-pastes your content seems like a good idea, until you find out what the content is and how you should be dealing with it to support business (not just IT cost-cutting).
When you do want to sort out the access for content, secure distribution or re-use with Generative AI tools - cut-n-paste will not help you. You'll need someone who understands migration to clean-up the mess.
The value in dealing with me (read: Spoke) is that I don’t just know how to turn it on and point the tool at a location, but I’ve also the knowledge of how to deal with a range of issues from:
optimal settings for routing, staging, and managing throttling,
best-practice on defaults, standard models for different content for specific processes
conversions of properties and metadata,
management of permissions, inheritance and rationalisation,
re-engineering your structure on the way to new store (IA),
common (and unusual) environment exceptions,
data-corruptions, mitigations and recovery, plus
analysis and de-duplication of content and reconciliation on completion
and those are the aspects I can be bothered to list
I ask the 'why' and 'how' to understand the objective in the migration and design (or re-design and remap) content to meet business goals from the move.
It is never just about moving some documents. Even from a file server.
When I tell you we use Sharegate, Tzunami or one of a dozen different types of migration tools it’s because I’m telling you of what type of tool I’ve used to 'create the chair' vs 'how it was made'; I'm not providing you the plan, wood-type and grain, sourcing options, assembly instructions or the years of experience of dealing with weird and wonderful (hair-raising) issues combining various glues, pins, varnishes etc. (see what I did with the analogy here 😊)
The value in talking to us is we are the people that understand what’s involved. We're a safe pair of hands. Success is not using a tool we say is good, or just using your in-house techie and hoping they get up to speed using the online manual and how-to video from the vendor, this can set you up for some nasty long-term issues with misunderstanding the real objective, or running afoul of uncommon issues you will encounter.
We use a range of tools, scripts, integration components, and even specialised schema and migration mapping software to draw the models when required. We know when to use which. We understand what each provides and what it doesn’t, and more importantly how to fill the gap left behind.
So, no I don’t have a problem telling you we’ve assessed and used a lot of tools over-time and we use: Sharegate, Tzunami, Migration Manager, PowerShell and others today – because we know which work, as well as when and how they do – and don’t – meet the need. That’s what we learned over the years of doing this in lots of different ways. Along with what not to do.
So, when the wheels do fall of the migration bus do not worry, we will be here when you need a hand to get out of the hole you are in.
Need help with content migration? Time We Spoke.
If you want to talk about migrating from: file servers, EDRM platforms, ECM solutions, SharePoint on-premises or other content repositories to Microsoft 365 and SharePoint contact us at: hi@timewespoke.com
About the author: Jonathan Stuckey
Comments