The only two pronouncements made at the beginning of a migration project are about the quantity of data and the date for the end of the project. If the first question can be confirmed, the second cannot; it is often theoretical, even impossible without a thorough prior study into the structures in place. Indeed these structures can often be major obstacles to desired expectations.

James Moody is a specialist in email archiving for approximately for 14 years as EMEA & APAC Channel Manager at TransVault.

We interviewed him on strategic issues to consider before launching a project to archivage.

One of the greatest challenges of my current role is explaining to potential customer s that archive migration can be quite difficult and that there are lots of questions that will need addressing before you begin.

The most common question I am asked is “how much will it cost?” and “How long will it take”? Of course it’s not quite as easy to answer these as you might first think.

For example, we would have to establish how much data is to be migrated. Do you want to migrate all data or perhaps a subset? What do you want to do with “leavers” data? Do you want to give end users a mirror of their existing environment in the target one or will they have a completely different view? (e.g. do you want to synchronise shortcuts?)

Once the data volume is established, how long will it take? Another question that is not straight forward. The variations in data migration rates can be significant from one customer environment to another.

For example, if one customer is experiencing a maximum achievable rate of 10 messages per second and another is 60 messages per second you can see that one could be 6 times longer than the other. If this project involves 100’s of millions of emails, the time differences could be very large indeed. So it is important for our partners to fully understand and communicate the project timescales to their customer. This is typically established with a short proof of concept (POC) during which many of the questions can be accurately answered.

Another question I’m often asked is “why can’t I just migrate manually”? The answer to this in most cases is “you can”. However this would assume that you are in no particular hurry to migrate, have a person who is willing to undertake the tedious task, and have no issues with the fact that you would have no accurate reporting to confirm that all emails had been successfully migrated (to the right users/mailboxes!). Therefore the advantages of using TransVault Migrator or Sprint would be speed, accuracy and  reporting to give assurance of successful migration.

For various reasons ( product developments, policy changes...) a company may find itself in the position of needing to upgrade its messaging system.

This is both a complex and strategic exercise. Sebastien Demond, from Optrium, explains why and describes in detail the different stages of a messaging system migration.

In what way is a mail migration delicate?
Mail migration is delicate because all companies, regardless of their activity, have a large messaging system content which also contains strategic information.

It is also the most widely used communication tool, bringing a legal concept which is increasingly demanded by companies.

The primary difficulty of a mail migration is the impact it can have on the jobs within the structure.

In addition, at Optrium, we work with extended messaging systems, which means that the messaging solution is made up of a standard messaging system such as Exchange or Domino, coupled with an archiving system.

This type of architecture adds a degree of complexity which needs to be taken into account and which needs specific expertise to ensure a successful migration.

It is therefore difficult for technical teams who are not qualified for this type of project to be able to fully comprehend the different stages, actors and engines which are needed. This is why we at Optrium are entrusted with the preparation and management of this type of project.

What are the key points to bear in mind before launching a migration project?
You must be aware that a migration consists of retrieving existing information from a current system (which is sometimes obsolete) and putting it into a newly deployed system using existing infrastructure. It goes without saying that the performance of the source, infrastructure, migration tool and target immediately impact on the migration’s performance.

A migration tool is not a corrector; this means that if information is corrupted at the outset in the source file, either it won’t be migrated or it will be migrated but in its original, that is corrupted format.

When you assist a client with a migration, what do you do?
We start off by informing the client about the migration process and its “limits”. In fact the client must be aware that a migration tool does not correct any migrated data.

This enables the client to reconsider his/her expectations about the results of a migration. For example, a client who wants to migrate 100% of his/her data will have to accept that this only means 100% of emails which are uncorrupted at source.

It is vitally important to define the needs and constraints imposed by the management of the company:

• Is it possible to consider a stop in service for users?
• Will interventions take place during the day or outside business hours/ days?

Once the constraints have been defined, Optrium works on the architecture of the messaging system in place and performs an audit to confirm that the existing structure does not show any weakness that could risk being “deported” to the new architecture.

After that the target infrastructure is put in place; this is installed according to the client’s needs, tested and validated by Optrium and by the client.

The longest and most important phase is the creation of the mail migration process so that the constraints imposed by the client are respected as well as any Editor’s “Best Practice”.

It does happen that some companies use their own migration tools; the risk in this case is that the editor of the target messaging solution (who ensures product support when the licences are purchased), renounces the support contract by blaming the failure on the tool used by the client. It is up to the latter to prove otherwise....

The last stage of migration is when the process is tested and validated before it moves on to its pilot phase and from there to production.

Optrium’s strength in this type of project is its experience and its knowledge of different migration scenarios in terms of clients’ systems, architectures, needs and products.