In more detail - The Clockwork On-Premise SharePoint Migration Tool
Reliable migration of documents from your old ECMS to SharePoint 2013, 2016 and 2019* (2019 still being proved)
We migrated just under 3 million documents, almost 1 TB of data, over the course of 9 weekends. Using 40 instances of the migration tools running in parallel across 4 SharePoint servers allowed us to condense almost 1,950 hours of migration into just under 67 hours! The tool was very stable and got the job done. - Shoosmiths LLP
Story of the migration: Migrating Millions of Legal Documents to SharePoint
From any SQL Server based ECMS (EDRMS, DMS, CMS) with files stored on a network drive or share. ECMSs like DOCs Open, Worksite, FileNet, Hummingbird DM6, etc.
- Migrate all versions and metadata (including managed metadata)
- Migrate to SharePoint libraries and folders
- Apply document level security if desired
- Currently in use on migration projects involving many millions of documents.
- Good for small migrations too - with a cost effective pricing scheme.
Will it work with your ECMS?
- Does your ECMS use Microsoft SQL Server for its database?
- Can you find the file path of your documents in the database tables?
- Can you copy a document from the file path and open it in its native application?
- You might need to rename the file extension of the copy (documents are sometimes given cryptic names like 1234.2, so rename to 1234.doc as necessary).
If you answered yes to each of the questions above then it is definitely worth having a look at the free trial version.
Note that the above tests verify you can access the documents without needing the API that goes with your ECMS. Instead, our Migration Tool accesses all the information directly from SQL Server, though you will need a good SQL person to write the necessary SQL.
Watch a 2 minute introduction to our SharePoint Migration Tool
[Ok, this video is old. An updated one touching on many of the updated features as well as the ability to migrate to SharePoint Online (365) is coming shortly. In the interim please feel free to ask for an online demonstration.]
CSw SharePoint Migration Tool - a quick introduction
Story of a migration ...
This is a short summary of how the Clockwork Software SharePoint Migration Tool fits in an SQL Server based ECMS to SharePoint migration.
So you’ve decided to use SharePoint to manage your documents. You’ve got many thousands, or millions, of documents in an old document management system like DOCs Open, FileNet, or Worksite, or maybe it is a custom built system with all the data in SQL Server and the documents in a (probably hidden) network file share.
Now, I’ve got opinions on best practise and so on in setting up SharePoint, but you’re here to read about the migration tool so I’ll focus on that and leave such thoughts for blog articles.
In a migration context, being able to quickly migrate a bunch of documents into a library so you can test out your content types, workflows, security, custom web parts, and all of that stuff is pretty important, not just for testing scenarios, but because your team needs to up-skill fast on SharePoint. It’s all very well theorising about how site structures will work, how the different metadata and versioning rules work, but sitting down and seeing it in front of you and using it makes it real and is very good test.
So the upshot of that is having the migration tool configured and working early on can be very useful.
Getting your migration tool working
Getting the Tool ready for first use on your own ECMS is quite straight forward in principle. If you’ve set up the Trial system databases then inspecting them will give you an idea, and the associated documentation should help you put it all into practise.
The main things to work out for your own ECMS database are:
- The SQL to return metadata about a document (one row per document). Usually this is hooking up your documents table to various metadata list and user tables.
- The SQL to return version details for each document, including the file path of each version (one row per version).
- If you plan to use document level security, then working out the SQL to extract the security information for a document and transform it to the required format is also needed.
- The fields you want to use for selecting documents to go to the various SharePoint sites and libraries.
Obviously there is a bit more to it that that but those are the most critical, and probably the hardest bits. If you know your ECMS database well, then you can probably do these bits quite easily. If not you will probably want to get a good SQL person to sort this out for you. Or you can talk to me as they all tend to follow a somewhat similar design pattern.
Once it is sorted out, you can create hundreds of migration runs very easily as all you’ll be doing is changing the selection criteria. Now you might be thinking, hey, what about the different sets of metadata for all the different groups of documents? With the Tool you actually do this at the initial set up – you get all the metadata you might need being selected and define the SharePoint fields they map to, but each migration run only uses the ones it needs (the ones defined in the content type for that run, or if none is defined then the default content type for the target library will be used).
Migrating & UAT
Once you have it hooked up to your ECMS the trial version will let you send through 9 at a time which is usually fine for testing. Or you can purchase a license. In both cases you can push documents to SharePoint, evaluate them, and then delete the run and have another go. And you can do that over and over again until you are happy.
So if this sounds like something you could use, register for the free trial and give it a whirl.