Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Tue 23 May 2017, 12:31 PM
"After a migration, it is essential that the original content, context and intent are clear, as there is usually little recourse to checking the original source. In our experience, approximately 5-10% of emails suffer from some form of fidelity issues, while 1-2% suffer serious data loss or corruption due to rendering issues. These numbers may range much higher for organizations who have a long history of integrating Notes mail with their applications." - Mitigating Risk of Data Loss – Migrating Notes Emails

Click on the link to read about ten problem areas, and how we help mitigate your risk.

CoexLinks Migrate - Whether you are converting, archiving or migrating, we ensure the integrity of your company's email. (Application data migrations also available.)


If the data matters, you want it preserved. If the data doesn't matter, why are you migrating it?

Inline JPEG image



Copyright © 2017 Genii Software Ltd.

Wed 3 May 2017, 01:17 PM
If you work with customer/client companies who currently use or are moving away from IBM Domino, and you might be interested in reselling any of our CoexLinks products, don't hesitate to contact me. Opportunities available in most regions of the world. If you work for an email vault or data warehouse company which might be interested in expanding to ingest Domino emails, either archived or live, from client companies, I'd be interested in talking with you as well.

CoexLinks Fidelity is for outbound/mobile/web email fidelity. All three products use out proprietary rendering engine for the best fidelity available. (Applies to Notes/Domino/Traveler/iNotes.)

CoexLinks Migrate is for either converting mail in place (for Verse) or migrating it out to disk or elsewhere for use in archival systems or new email systems where all email is desired in a single place.  (Applies to Notes/Domino/Verse)

CoexLinks Journal is for journaling email into a secure vault or data warehouse for compliance, surveillance or analysis.  (Applies to Notes/Domino/Verse)

Below is an example of the importance of the high fidelity rendering. Whether you are sending email to clients, journaling or archiving it for later retrieval, or migrating it to another email system, you should expect at a minimum that it contain all the information in your email and that it look roughly similar. If you sell a CoexLinks solution to a client, you can have confidence that the fidelity will be top notch, and the data will be retained.



Copyright © 2017 Genii Software Ltd.

Wed 3 May 2017, 11:54 AM
I posted this over on Facebook, but though I'd share it here as well. We've been doing some performance tuning on CoexLinks Migrate, which let's you export your email, both MIME and rich text, to high fidelity standardized formats including MBOX and EML and Exchange Mail Journal Envelope format (basically a wrapped up EML file with all the recipients and such in an envelope.

Performance tuning is fun, but it isn't sexy. You take Software A which creates End Product B, work incredibly hard to make sure it still creates the exact same damn End Product B, but faster. Same input, same output, less time. Not sexy.

But it can be satisfying. Here are the results from my test this morning (run on an old PC, so your mileage may vary, but it is likely to be better).

Inline JPEG image

Performance tuning seems to be helping. This is exporting to MBOX format, which is much faster than individual EML files, but 6000/minute means averaging 1/100 of a second per document. Wow. This generated an MBOX file with size 0.93GB from a mail db of 1.62GB, for what it is worth. When I ran the same test on the same database generating EML files,  it did about 2600/minute and generated 1.8GB in total EML files. That's overhead for you. 

In case you wonder the practical needs for this kind of speed, we have a client with 5TB of archived email. Using a very rough approximation based on my own mailbox, that would take about 96 hours (approximately 4 days) generated to MBOX. It would take roughly 220 hours for EML format (approximately. 9 days). 

When we started tuning, it averaged 950/minute for EML (we didn't measure for MBOX then). At that rate, it would have have taken 602 hours (approximately 25 days). Now, because these are separate databases, you would either run it on multiple processors or multiple machines, but even dividing these numbers by 10 machines/processors would take 9.6 hours, 22 hours and 60 hours respectively. The longer it takes, the more chance of something going wrong and having to start that part over. In short, speed matters. Fast enough, and you can even re-do the whole thing if some assumption turns out to be wrong. Slow enough, and a mistake can make you miss deadlines.

But as thay say on Reading Rainbow, you don't have to take my word for it. Request an evaluation license today and give it a spin.

Copyright © 2017 Genii Software Ltd.