Migration 101 - SharePoint DM and Migrating the Clockwork way
How I approach a migration...
The inquiry, and some questions
Things usually begin with an inquiry about what’s involved, how much it will cost, and how long it will take. I usually reply asking for some information about the overall project to give me some context, and some specific migration related detail.
The answers I get to start with are often quite big-picture, but I can usually give a bit of an idea. For example, for a few hundred GB of the same sort of files something like the following would not be unusual:
- Preparation & testing to get to the point of migrating - a week of consulting time, maybe two if issues come up. This would usually be spread over a few weeks
- Migration itself could get enough done over a weekend to allow go-live on the Monday, with another two to three days finalising.
Of course, the answers that came back may mean I can be a lot more precise than that, but there are usually still a whole lot of unknowns. Things that affect the timing and costing include:
- Data quality
- Number of different types of data to collate
- Whether implementing the desired mapping rules to SharePoint turns out to be simple or complex
- Internal resource skill levels and availability
- Internal environment network speed
- The actual volume of data adds time overall, but once routines have been established it becomes fairly straight forward.
So I’ll usually suggest a small investigation as the next step, with the aim of confirming the details.
The first action - an investigation
The first step is an investigation to:
- look closer at the source system
- check if the environment is going to throw up any issues
- assess how well the data is going to map through to the planned SharePoint configuration
- come up with some more accurate costs.
If you want us involved in this then ... our general approach is to look at each business area, or use case, and come up with an associated "SharePoint design".
A "SharePoint design" is a combination of columns & content types, and site, library & folder configuration.
As a general rule we aim for a basic design that only needs a tweak or three to apply in each area.
Then we can set up some of the designs in SharePoint and users can test them out in a proof of concept.
Proof of concept
This is usually about users testing the proposed design. Sometimes it is done with test data, sometimes it is done by setting up an area and using it for real.
There are two roles for migration in a PoC scenario:
- Migrating some live data so users can work with real content. This isn’t always required
- Migrating a significant volume of data into the PoC structure to get metrics on how long the migration will take.
The first job is to organise the "migration runs". A “Migration Run” is a logical grouping of documents to migrate together. It might be HR documents, clients A to E, projects completed in 2017, documents created between two dates, or anything that works for your business.
Preparing “Migration run” data
For iManage, eDocs and other traditional DM systems this requires making SQL Server Views to collate the documents for each migration run.
For SharePoint to SharePoint migrations this might be a set of site collections.
Checking the data
There are various checks here depending on the type of migration. Things like:
- illegal characters in names
- files of the same name targeted at the same location
- do files actually still exist - in a DM system over 7 years old it is very likely a few hundred documents per million will have got corrupted, usually due to Word crashes, or network glitches.
If the target structures (sites, libraries, folders, document sets) need to be created then "creation runs" need to be set up and run.
Then we can migrate each migration run. This process is usually a few hours to a few days so involves monitoring, error checking, and waiting.
Once a Migration Run is complete we need to verify the documents arrived where we expected them to be.
Migrating “deltas”, or what’s changed in the old system since the migration
Often users will be using the old system while the migration is in progress. This can lead to documents being updated in the old system after they have been migrated to Sharepoint. These are often termed "deltas" and need to be remigrated.
There are several strategies for managing deltas. Firstly:
- leave migrating documents edited in the last few (3?) months until the end, or until the user group likely to use them are about to transition to SharePoint.
It’s highly likely these can be migrated the night before go-live, and it will greatly reduce the number of deltas
- deltas can easily be identified as their last modified date will be after the migration run happened. They can then be packaged up to redo.
Working with Clockwork
When you choose to work with us you can choose how much you want to use us.
Our preference is always to up-skill your team and have them do the work with confidence, but we are quite happy to do it for them.
And we are always happy to work with, or sell through, vendors who have an expertise in migrating to SharePoint.
Rates are on the pricing page.
You can purchase our products and do the work yourself. We like to see you get off to a good start so will generally be pretty helpful, and you can always purchase a few support hours so you feel free to ask us anything!