Escaping Vendor Lock-in: Life After Microsoft Exchange

Appendix A Appendix

This appendix describes additional information on migrating your messaging platform to Sun Java System Communications Services.

About Message Storage Concepts

When performing a messaging migration, no migration tool has access to the low-level interfaces of the stored mail messages. This becomes problematic when dealing with a message that has multiple recipients and thus might be stored multiple times in the mail storage.

If the messaging system supports it, you would want to store just a single copy of the message, and then through pointers, enable the multiple recipients to reference that single copy, thus reducing overall storage need. That is, you don't need to store a duplicate copy of the message for each recipient. Both Microsoft Exchange and Sun Java System Messaging Server support this single-copy storage scheme.

Statistics show that a typical multiplication factor for a message store in a corporate environment is between five and ten. Obviously, you do not want to increase your message store during a migration from 500 GB to 5 TB of disk space because of this issue.

Note that this issue is faced by all migrations, and does not uniquely apply to Sun. What Sun states is that this is a “non-problem” when migrating to the Sun Java System Communications Services platform. Though one cannot compare directly the message store models of Microsoft Exchange and Sun Java System Communications Services, you only need an equivalently sized storage for the migration.

Figure 1 illustrates the idea of the single-copy message store.

Figure 1 Single Copy Message Store

This diagram shows how the single-copy message store retains
only one copy of a message, even if it is sent to multiple recipients.

The figure shows that only a single copy of any message is saved in the store as a single file. All other instances of that message (for example, when a message is sent to multiple mailboxes) are stored as links to that copy.

The problem that a migration is faced with in making sure that storage expansion does not occur as it copies these messages to the target platform is illustrated in Figure 2.

Figure 2 Migrating Messages

This diagram shows how migrating messages to a new platform could
cause the need for more storage.

To prevent storage expansion from happening, Messaging Server contains a relinker feature to remove excess message copies, and instead, use hard links to a single copy of the message. Figure 3 illustrates how the relinker works.

Figure 3 Migrating Messages with the Relinker

This diagram shows how the relinker works to use hard links to
a single copy of a message.

You can enable this feature in real-time or run it as a separate command-line utility. The relinker enables you to identify those messages that are identical and to relink them in the store. In this way, you do not need to increase your storage requirements for your messaging service.

For more information on this topic, and on the Messaging Server relinker, see Relinker Theory of Operations in Sun Java System Messaging Server 6 2005Q4 Administration Guide.