Good morning all!
I feel like I have to start this post with the following disclaimer: I am not looking for sales calls / emails / solicitations!
Has anyone done any research, or actually used, any of the tools available to complete document migration from a file share into Sharepoint? I am trying to develop an estimated cost of some of these tools in order to propose a solution – Again, I am just seeking a range of costs, not specific data or sales.
Thanks for any help!
Pitney Bowes Inc.
I my previous life I was a sharepoint consultant and did quite a bit of migrations. In the end what I learned is that you spent most of your time figuring out what is in the file shares and where to move them to in Sharepoint.
Once this was done, in my experience, I hired a good Powershell developer who wrote specific scripts, tailored to the needs of the project. Usually this was done in 20 days or less. I have no idea on the daily rates of the PS scripters in your area, but in my situations that was way cheaper then tools.
We had very good experience with Metavis, which I think it now part of Metalogix’s suite of products.I think we use a different/additional product now. I’ll check with our admin and get back to you.
American Nuclear Insurers
FileFacets has a migration tool that can help you identify Redundant, Outdated, and Trivial documents to help you clean up your data while migrating to SharePoint. Full disclosure, we are a partner of
FileFacets. FileFacets Migration – FileFacets
FileFacets remove preview
FileFacets Migration – FileFacets
View this on FileFacets >
Accelerated Information Systems
Bump @Rosa Munzer …great reply.
Don’t make the mistake of missing the point of migration, is there value?
Come at it with a strategy to maximize the value. I would also give the bump to the others who point out the ROT problem here. Not only eliminating it before it gets in a repository, but part of the strategy has to be how do you control garbage getting in later?!?
Especially true with Sharepoint where many organizations already have users with power to create and add content, you may need to do a bit of extra work to look at and clean the existing data/processes in SP already. Once you have defined your need, and before committing to Sharepoint ask the questions you have and can SharePoint deliver? A mistake that is often made because of the ease of access to Sharepoint is to start with a tool and go at a problem. The right method is to discover the problem and then go looking in the toolbox for the right tool.
As noted by others, FileNet and OpenText have tools where you can leverage a team-site/work-in-progress from SharePoint and archive the records leaving pointers/stubs in Sharepoint — and in my experience, giving more value.
Good luck you can do it!
We did an assessment of around 5 migration tools from simple to very sophisticated for migrating from fileshares into SharePoint. A lot of tools’ costs are based on volume of documents migrated which as we are totally moving to SharePoint, would have been cost-prohibitive. We settled on ShareGate. Relatively inexpensive – we found we would only need 5 licences at any given time. Fairly simple to use and allows you to update metadata ahead of time in a spreadsheet before actual migration. This allows users to do the upfront work while we can do the actual “migration”. We have successfully migrated files using this tool.
AvePoint and Metalogix are the heavy hitters in this space and ShareGate is a lower cost, though not as fully featured, competitor.
I would start with some foundational information management questions before you determine the technology solutions. You can spend a lot of time and money moving records with no benefits. Will you manage new records differently then old ones? What is the value of moving files from Shared Drives to SharePoint” Do all files need to be moved?
Can you distinguish what File Share content is active records and what are Transitory? For example, if there are file share folders that contain records that are near their disposition date, then I would change file share access rights to read only and manage them in place until the disposition date is reached. If you are using file Shares to store records, do not confuse the fact with the records have not been accessed in a long time with the ability to delete the records. No one may have used them, then the records may not have reached their records disposition date. For example no one may have access the 2012 May month end financial report, however, financial records are retained for 7 years so you can not destroy it (I would manage it in place).
SharePoint has some limitations such as maximize size of sites and documents that can be managed hat make it problematic for use as a record keeping system. Large projects quickly exceeded the maximum size. So you may then need a strategy to move the Records from SharePoint Workspaces to a record keeping system.
We had to develop interfaces to declare records from SharePoint which we used for collaboration ( create documents, media,metadata), to move Corporate Records to our record keeping system FileNet (leaving only stubs in the SharePoint site that point to FileNet). We delete Transitory records from the SharePoint site and leave the site in read only for a period of item so users can leverage the stubs.
BC Hydro –
Thank you all for your responses. Believe me, I fully understand ROT and record retention. As for Sharepoint, we are already there – My issue at the moment is that I need to decommission a document management system used by the Corporate Legal groups in a very short time – After much research (and frustration!) I’ve determined that the fastest way to do this would be to do a mass migration into a read only library, give people a set time limit to migrate what needs to be preserved to an established library, then do a mass delete. I know this is not the best way to go from a RIM perspective – but based on my timeframe and lack of staff, it’s looking like the best option. I can migrate files using Windows Explorer … but the ability to use a tool would make my life easier!
[Pitney Bowes Inc.]
I wanted to throw in a few suggestions from my previous personal experience that might help. If you are migrating a variety of types and classes of content, you might want to plan and design several sites as destinations. Some things that can help design site functionality include:
Look at where duplicates are being made across departments or functions, and build a site around that overlap. There is obviously a need for someone to share that content- or they wouldn’t be duplicating it.
Analyze your content to see where naming conventions and taxonomies are already in place, and re-use those conventions. I have found 30 or so different formats, for example, that people use to tag folders with dates. If you pick commonly used ones in your SharePoint site, it increases adoption and makes conversion/migration easier.
Also look at your content for supporting technologies that may be required long term in your SharePoint infrastructure. Look for databases, images, photos, emails and compound documents to identify needs for integration, scanning, multimedia, email capture, or other add-ons. Your shared drive content will help prioritize the need for these additions.
Consider how you are going to automatically tag migrated content with status, project codes, lifecycle triggers, owners, etc. Automating that tagging process will add value when you use the file migration tools mentioned in previous replies. Most migration tools allow you to copy in metadata when migrating
The evidence you need to make informed decisions about these things resides in your content. If you are migrating just a single type of content with no metadata, these recommendations won’t really mean much.