Cloudification Top Tip #3

Look carefully at the data to be migrated.

This week’s CloudCIO blog entry continues our series of Cloudification Top Tips, with a closer inspection of the physical data migration itself and how you can prepare yourself for success in what is possibly the most challenging and time consuming of the migration exercises.

Microsoft (unlike Google) have some limitations on the number and naming conventions of files

that can easily be migrated (due to the fact that OneDrive for Business files are stored online in an SQL Database): for example, MS O365 OneDrive for Business synchronisation to a local drive was until recently, only possible for repositories of less than 20,000 files and no single folder could contain in excess of 5,000 files.  MS are in the process of trying to address some of these limitations, and have recently (Oct 2015) released an improved version of One Drive which removes the 20,000 file limitation and permits individual folder synchronisation to different devices.

It’s still possible however,  that some files still may not migrate to the cloud – typically these are empty temporary files that may not have been closed properly in the event of a power outage to a user’s machine, make a note of these, and check that the originals exist (though they could have been subsequently deleted).

Trim excessive file and folder name lengths to more manageable sizes.

MS O365 has a limit on path names (of 256 characters) so filenames and folder names should be kept as short as possible to avoid hitting these limits.  Check that the file names do not contain prohibited characters.  Invalid O365 filename characters include the following: @#%$&{}~  and  double dot’s ‘..’, or filenames that begin with a dot!

Google (Drive) places no such limitations on numbers of files, path lengths or file naming conventions (prohibited characters in filenames or filename lengths), but be aware that you may hit these if you subsequently move your data files from Google Drive to another platform (or email them to someone using a different platform!).

Trim unnecessary, duplicated or redundant data.

Just before a migration is the perfect time to remove any old or duplicated data from your repository, possibly to archive if you wish to retain a copy (though you should have already made a backup if you have been following these tips for successful cloud migrations).  This will reduce the data footprint in the cloud and its speed of load (large data uploads to the cloud can be slow, especially if you are using a mapped drive rather than local drive synchronisation – which can work in the background)

Moving data files is only part of the story.

If your organisation is a heavy user of email, and specifically currently based on MS Exchange (though other platforms may also pose similar challenges) then you will need to spend some time planning the migration of your mailboxes.  This again can be a time consuming and complex process especially if you have an archive mechanism in place, or if mail attachments are stored separately.

Use tools.

Tools now exist that will assist with this process, for example the multithreaded CloudMigrator365 (for various mail platforms and also data files) and CodeTwo Office 365 Migration (MS Exchange only) to name a few, but others may be required depending on the complexity of your environment.  Depending on the components you license, Mimecast’s Unified Email Management can help with on premise, hosted, and Office 365 deployments.  This fills the gaps around enterprise-grade archiving, antispam/antimalware, continuity, and large file sends. The archiving feature, can ensure that users can access their sent and received email and restore it if necessary themselves, saving IT admin headaches.  They can’t however, delete archived emails, so your organization’s e-discovery and compliance remain intact.

Run data load tests.

Both on specifically selected (for volume/complexity) and random subsets of your data, these will give you an indication of your likely load success,  indicate approximately how long it will take and may uncover data migration issues early in the process.

Build and use a test environment on the platform.

Of your choice for this purpose, and tidy this away after the successful completion of your migration.  Be sure to document any issues you uncover as these will all require resolution before attempting the migration.

If the data is large you might consider performing the migration in chunks (by department, or office location for example) but experience has shown that in this scenario a big bang is often preferable as the help desk only takes one, concentrated, hit, rather than having it drawn out, and the same issues repeated.  Issues that are resolved (in terms of data loading) for one group of users, will typically solve them across the board.

Access control will need to be replicated to the cloud platform.

Normally, the more users you have in your organisation, the more complicated your data becomes, the more likely you are to have different access rights for different users and groups, on different folders and files.  It might even be the right time to re-think how you simplify your document control organisation for ongoing ease of use.

Access control in the cloud operates a bit differently to the way it operates on an on premise file server.  Typically, users of cloud storage provided with an O365 or Google Apps account will have a quantity of online, cloud storage associated with their account (Google Drive or MS OneDrive).  O365 Admins will be able to configure the generic types of sharing between divisions and departments, but users will need to specify how and with whom they wish to share their specific data, either everyone, or other groups and individuals within their organisation, or no-one.  You will need to document these access right rules and ensure (test) that they have been correctly migrated to the new platform.

Training should definitely be considered for users in businesses with complex organisational hierarchies.

Avoid underestimating the complexity, time to fix any data issues and re-loading of data onto the cloud storage mechanism, through thorough iterative preparation and testing the migration of your data.  Use a test environment and don’t overlook the necessity for just-in-time user training.