When your organisation is moving to a new platform, all (or at least a part) of your data needs to be moved as well. There are many ways to tackle this, like buying or building a migration application, but sometimes it can pay off to leave it up the users to migrate their files.
When we are talking about documents, most systems have a way of dragging and dropping files into the new system. Let’s take a look at some of the good, bad and ugly that comes with this way of migration.
If you have a big organisation with lots of users and files, it could pay off to let the users move their own stuff. By dividing the work into little chunks, the workload becomes more bearable for your IT team. And after all, because the documents belong to the business, they know where they need to go and what needs to happen to them. They have the knowledge to know what files are important and what can be thrown away. Letting the users migrate files will reduce stress to your migration team and save a lot of money and time for the organisation. And last but not least, by letting the users move their stuff, they will know where it is because they put it there.
On the other hand, business users already have their hands full with doing business. They don’t have time or don’t feel like doing such a mindless task to move their documents over. And that one folder that is 7 year old? Users don’t know if that can be thrown away. Maybe they still need it later. Overly cautious users might still cling to “their” information and keep it just for old time sakes or “in case of..”.
Migrating files into a new platform can come with its price: metadata tags are lost, you lose who created the original document, policies and retention dates get lost as well.
If you were using a fileshare solution maybe you would still use a v1, v2 and v3 suffix in your document names too. How are you going to handle these as well without adding the garbage in the new system?
What about security? Maybe a specific folder had special security rights that the user appointed to migrate them didn’t know about.
So when is it useful to let business users migrate their own documents?
In the past, I have done migration projects for large customers that have world-wide offices and lots of departments. Every department feels different about how they should be treated and how / when they want to migrate their files. In this case, it could be beneficial to teach them about the new platform and let them do the migration on their own terms.
For projects where speed is important, drag and drop migrations could work as well. If the original metadata and creation date/author is not that important, migrating documents like this could work as well.
Succesfull drag and drop migration
Make sure the users get sufficient time to tackle the migration. Schedule some time in their calendars, talk to the managers to get it approved. After all, you need the management buy-in you to make sure this can happen.
Next, see to it that the users understand the new platform. Make them feel comfortable using it. Teach them about policies, retentions, version management so they know what will happen with their documents. And even more importantly, make sure they know how to get there! Bookmark the page, put it in their favourites, set their homepage to the new location,… Do whatever you can to make sure they can work just as easy with the new system.
Create a good backup of the original location, make sure that if they miss any files, they will still be retrievable for a number of time by IT. This could be 3 months or a year.
Give the users time, clear instructions, a deadline, motivation and the knowhow and they will handle that migration for you!
At Bloom, we take all kinds of migration paths into consideration. If certain parameters ask for it, a drag and drop migration could be the answer an organisation needs.