Earlier this year, we started talking about this fascinating area of data, or content, migration.

It’s such a huge topic that we only just touched the surface, so I think it’s time to go back and review some of the critical issues there. So why does an organisation need to migrate anything in the first place?

In most cases it’s because lot of information has accumulated over time and such legacy information often represents a significant collection of hard-won organisational knowledge. This ‘corporate memory’ is going to be lost if they move to a new system, simply because of the fact that technical incompatibilities may mean it can’t be read in a more modern system.

Is ‘content’ what I put on the website?

By the way, we should point out that the term ‘content’ is often mistaken for the information you have displayed on your website. And yes, the term ‘content management system’ is often used for technology to help you manage information that sits on your website – but it should also be understood to embrace what we are talking about here: the physical and electronic files in your organisation and also the data associated with it, which can be quite an extensive and complex structure to work with.

Other terms in this context may be ‘document and records management system’ and  ECRM.

If that is the content we are referring to, what is the target of a content migration integration project? The sources of data and information we come across are file systems. There are, as many of us will know, all sorts of file systems dotted around the organisation (a fact that in itself provides some challenge). Usually, that can be defined as ‘unstructured’ data.

Then you have got more ‘structured’ data, like the sort that sits in databases, connected to a number of different applications. These ‘databases’  can be simple things like Access all the way up to a large Oracle or Microsoft SQL Server type database, which tends to have a lot more information and a lot more relationships, which again means a lot of challenges.

You also have the legacy content management systems, which have ended up out-dated and needing to be replaced. These could either be bespoke or commercial, e.g. it could be based on Documentum or SharePoint, Open Text, or any commercial package that’s either on (or used to be on) the market. The specific problem with outdated commercial systems is that often the knowledge and skills around those systems has been lost some time ago.

Last, you have all the e-mail floating around – which will probably be the biggest container of information in an organisation these days. That’s because the contributors to the organisational e-mail system are not just your internal people, they are all your external contacts – plus the emails are often in the form of lots of documents coming in via attachments.

A model that is useful is thinking about two groups here, the contributors, people who put content into the system and the consumers that access that information and search for it and read it. Note that the volume of contributors to the e-mail systems is far more significant than would be if your content was only coming from the file system/databases/legacy content management system.

These are the sources of information – and the mass of information, in all their different formats, that we need to manage when we start a content migration service engagement.

Next time, let’s look at how to migrate all this stuff, which we now better understand as ‘content.’