Transferring Email, Addresses, and Calendars

Off the Beat: Bruce Byfield's Blog

These days, you would think that transferring your personal data -- email, address books and calendars -- between applications would be a matter of a few mouse clicks. And, occasionally, it is. More often, however, transferring your data between Kontact/KMail, Evolution, and Mozilla (Thunderbird and Sunbird) is an unsystematic affair, with too many steps and kludges. No matter which of these applications you are transferring from and which you are moving to, you need to expect the unexpected.

From Evolution
I first discovered what a ramshackle affair moving personal data can be a few weeks ago, when I switched from GNOME to KDE for my main desktop (no great statement there; Debian simply got around to including a reliable version of KDE 4.2, and after several years I felt overdue for a change.

At first, I thought everything would be easy. From KMail, selecting File -> Import Messages brought me to a wizard that transferred my Evolution email to sub-directories of a new folder called Evolution-Import. I would have preferred to have the option to import folders at the top level, but, with a little copying at the end of the transfer, I had what I wanted.

Then I discovered that I could not transfer my Evolution address books directly, because they can only be exported as vCards. Once I did that, Kontact imported them without any problem, although I suspect that a user who relied entirely on the desktop might have had some.

Still, those were the smooth parts. Evolution can backup calendars, but includes no way of saving them to another format. Nor would Kontact recognize them, even when I moved them to the top level of my home directory, which was the only place it would search for them. However, when I opened one of these .ical files from within Dolphin, it opened in Kontact, allowing me to access it at last. Someone less determined or more impatient would probably have given up long before -- that was three different ways of transferring the information.

But, when my curiosity took me beyond my immediate needs, I discovered that the inconsistency was just as great elsewhere. Trying to transfer email from Evolution to Mozilla Thunderbird, I thought I would have an easier time, because of the Tools -> Import function. However, on closer examination, all I could import was emails from old versions of Netscape Communicator, an application I hadn't seen for almost a decade. Instead, I had to copy Evolution's .mbox files over to Thunderbird's directory after recreating the Evolution directory structure.

Copying contact from Evolution to Mozilla proved another process. I could export an Evolution address book to a vCard, but Thunderbird does not support vCcards, so I needed to take the intermediate step of importing the address book to Kontact, then exporting to .ldif or .csv format before importing it into Thunderbird at last.
However, I did get a break on calendar information. Since Evolution calendar information is stored in .ics format, transferring an Evolution calendar to Mozilla Sunbird is only a matter of selecting File -> Import from Sunbird and navigating to it in a file manager.

From Kontact
Following my curiosity, I decided to try migrating from Kontact. Evolution, it turns out, has an Import function in the file manager, but that is mainly for what it calls "older" formats, meaning Pine, Netscape, Elm, and iCalendar. For files from other programs, you need to import a single file in a recognized format. Unfortunately, Kmail has no export function, and the native format is not among those Evolution supports. The only solution is to create a false account in Evolution, setting the server to Maildir-format mail directories -- something that frankly would never have occurred to me without an Internet search.

After that, converting data from other Kontact applications seemed blessedly simple. All I need to do was convert my address book to a vCard or a .csv file for importing into Evolution, or export my calendars to .ical format and drop it in the right directory in Evolution.

To transfer emails from Kmail to Thunderbird, I was back transferring files directly. Address books were easy, because all I needed was to export them into .ldif or .csv format, both of which Thunderbird can import. And, once again, exporting to .ical format allowed me to transfer calendars.

From Mozilla
In contrast to these tactics, migration from Mozilla is consistent. The process is the same regardless of whether your target is Evolution or Kontact/Kmail:

• Email: Copy mbox files from the Thunderbird directory to the Evolution or Kmail directory.
• Addresses: Convert to .ldif or .csv format, then open the target application to import.
• Calendar information: Select File -> Export Calendar, and save a copy as .ics or .csv, then open the target application to import.

For email in Kontact, I also had the option of opening the Import Wizard to help guide me. And, if I had wanted to make things easier still, I could have added the Thunderbird Message Filter Import/Export to do most of the work for me.

A long way to go
By the time I finished mapping out the different migration tactics, I had spent the better part of the afternoon. But, long before I had finished, I realized that, the occasional wizard or import/export function not withstanding, support for interoperability can still be a bad joke on the free desktop.

This state of affairs is partly a matter of usability. Anyone who confines their computing to the desktop would be lucky to successfully switch their information from one of these applications to another.

More importantly, it seems to me that interoperability is the main reason why the free desktop can get away with allowing so much freedom of choice. So long as you can move your information where you want it, the application in which you view and use it shouldn't matter. But, in the case of personal data, where it is located can matter considerably when you come to move it.

You would almost think that the development teams for these major applications were reinventing vendor lock-in to keep their user bases from becoming too curious. You could, of course, start afresh each time you chose another application set, but that would mean keeping previous choices around just on the offhand chance that you needed them. The process of moving your personal data around should be seamless, and I can think of few reasons except lack of attention to explain why it isn't.

Comments