Implementing an EDRMS usually starts with the establishment of policy but quickly turns to training and the migration of data.

Migration can include:
- migration of legacy data from old RM systems
- migration of paper records to scanned renditions
- migration of e-docs from network drives and other storage
- migration of e-mail
- and any number of other sources

Firstly, given the seriousness and emotion that data migration raises, our view is that a formal data migration document should be prepared detailing the who/what/how/when of the data migration - this document should be widely circulated and approved by a senior sponsor of the system.

The key issues to consider when planning the data migration include the following:

Firstly, during an implementation, the rate limiting step is often training.
However, migration of users' data should be as close as possible to training and subsequent post-training support (important for the effectiveness of the training) but it cannot be before (otherwise they often cannot perform their job). This means that training and migration have to be sequenced together in a way that can actually be executed which can require careful planning.

Secondly, the relationship between the structure of information of the network drives (i.e. the folder hierarchy) and email system (i.e.
folders within users' Inboxes) typically does not match the desired structure within the new records management system or even the paper filing system. Therefore you have to work out how to map (or even if whether you should bother to map) the old classification structures with the new system. How this is mapped, if at all, can be on a group-by-group basis and may involve some manual steps.

Therefore, training and migration often follows these steps:

1. Identification of training strategy (self directed, virtual classroom, real classroom, post-training support).

2. Identifying groups that can be practically trained and their material clearly identified on the network drive and legacy systems. Note: sometimes it can be good to institute a 'clean-up' (yes, with lots of consultation) *before* migration to neatly separate all the components for step 3, and sometimes it is better to do this *after* migration.

3. Sequencing repeating instances of training/migration, making the applicable area of the network drive r/o as you go. I would also consider the sequence going from 'friendly' to 'hostile' as a change management strategy or 'supporting' to 'operational' where you want to minimise risk.

4. For email, users are typically trained on how to place their own email on file (usually in bulk), which is guided/pressured by post-training support personnel and by 'screwing down' the maximum inbox size (with plenty of consultation of course!). Sometimes, rarely, email migration can be performed at a technical level from the server but this depends on how complex any mapping might be...

5. There is always a residue of unclaimed material on the network drive, such as 'common folders', which you will have to work out how to handle (all duplicated elsewhere? delete? migrate to hidden folder in EDRMS? panic?)


Naturally, there is no one-size-fits-all approach so please feel free to contact us for further advice.