Progressive migration is a step forward

This is the first of a number of articles that I will be writing about data migration in the coming months as this is a subject that has for too long had no clear focus, with companies tending to think of data migration as an afterthought to such things as application consolidation or SOA. I will return to those subjects in further articles. For now, I want to concentrate on what has been dubbed ‘progressive migration’.

Progressive migration is the brainchild of Celona (whose name derives via arcane means, that I will not discuss, from Barcelona), which is a UK-based company that specialises in migration for the Telecommunications market, though its technology is not limited in its applicability to this sector.

What Celona aims to do is two things: first, the migration itself should involve zero downtime. Nowadays, with globalisation and 24×7 working, nobody can afford to have even planned outages, so zero downtime for migrations is increasingly a must; secondly, Celona gradually phases operations over from the original system to the new one (which is what it means by progressive migration), so that you do not have any big bang cut-over point. It also means that you start getting value from the migration at a much earlier stage and that that value is incremental throughout the life of the project.

The main point that I want to highlight is the fact that Celona uses three different kinds of modelling. The first consists of conventional transformation models, the second of rules that reflect business processes (something that is typically absent from standard ETL platforms) that enable greater reuse than traditional approaches, and the third is a state model.

The state model is especially important in enabling progressive migration because it means that the software is aware of the current status of all data and, if it has been migrated, where to and when. Thus you can have your software running partly off migrated data and partly running of data that has not yet been migrated. This can be achieved by inserting flags into the original system (this is by no means a new concept) or by using web services or you can directly interrogate the Celona state model. A secondary benefit that the state model provides is a complete audit trail of the state of the migration and the third is that you can back out of any subset of the migration by making a relevant selection against the state model (for example, migrations made during a specified time period).

So that is the migration itself but as this is a continuous process rather than a batch one, you need to make sure that there is no impact on the performance of the applications that are using the data. To ensure this Celona provides a graphical front-end that it calls the Migration Controller, which allows you to throttle the migration processing so that it runs in the background in such a way that it does not adversely affect live transactions.

The concepts behind Celona’s software are clever and I have not seen anything else like it. As the company’s background is in Telcos (it started life a decade ago as an SI for BT) I am not surprised that it is specialising in that space but it would be worthwhile for the wider market to have a look at Celona as well.