top of page

What to consider when migrating iManage WorkSite to SharePoint

Updated: Feb 20, 2018

Some thoughts about the technical challanges - Part A.


When migrating one document management system to another you will run into challenges. The main challenge is the difference in the source to the target, Typically you will find features from the source system that are missing in the target system or they are available but configured completely differently.

When migrating from iManage WorkSite to SharePoint you will come across plenty of those scenarios. First of all, the concept of document versions in iManage WorkSite is very vague. Every version has its own set of metadata including security. SharePoint on the other hand has only one set of metadata and security assigned. Consequently, for the migration the best practice is to take the security of the last version for the document in SharePoint and migrate each version across in the same sequence, so they get the same versions numbers in SharePoint as in iManage WorkSite. This implies that you use major versioning only in SharePoint.



You can take the hassle out of any DMS migration project by relying on prefessional software like OrbitMigrate.




Security itself is another big topic. The concept is completely different in iManage vs. SharePoint. In iManage you can have all sorts of users including virtual ones that do not need to exist in any LDAP system (e.g. Active Directory). While you setup iManage WorkSite you specify which security model you want for each library / database. There is an optimistic model which means that if you have contradicting ACL entries on an object (e.g. on the document security tab) the higher one wins. To give you an example: If a user has read access to a document and a group (which this user is member of) has write access that that user has write access. Obviously, when you set it to be pessimistic the lower one wins (the user would have read access only). Here it doesn’t matter if the setting is for a specific user or group which the user belongs to.

In SharePoint, which tries to mimic a typical (windows) file system, a user setting will always overrule a group setting. There are scenarios from iManage which can hardly be rebuilt in SharePoint unless you want to resolve every group membership to its list of individual users during the migration which is not a good practice. It’s better to redefine the security and let if be controlled from a leading system (e.g. Practice Management System or Content Management System). iManage WorkSite itself does not have a concept on inheriting security from a folder/workspace to documents. That’s mainly because a document can reside in multiple locations which all are equal ranked, whereas in SharePoint - like in a file system - a document can only be in one spot. If a document can be linked in multiple folders that means it cannot inherit security at all because the folders security settings might differ.

SharePoint itself uses the concept of security inheritance which should really be heavily used. Breaking the inheritance for documents is possible but this should only be done when really necessary. It will blow the Content Database and slow performance down. Also, there is a limit to how often the inheritance can be broken for each Site collection. That limit depends on which version of SharePoint you are using (this includes SharePoint Online). It will also make administrating those documents a nightmare.


What I have explained above is only some of the challenges you will face when migration documents from iManage to SharePoint. We at Galaxy9 developed a migration tool called OrbitMigrate which will handle all those scenarios (and more) and helps you to have a smooth migration experience.


If you want to know more about OrbitMigrate or hear about some of the recent clients that have made the move please contact us by clicking on Contact!


You can get to the OrbitMigrate product page here.


0 comments
bottom of page