This section describes the very few limitations in the conversion that Olminator can perform on an exported .olm file and in the creation of .mbox, .ics and .vcf files respectively.
Losing information in a conversion process and finding this out only days, weeks, months or years later, can be an annoying or even catastrophic experience. Hence, Olminator tries to maximize the retention of information from the input .olm file in the created output files as much as possible. While there are no intentional limitations imposed by Olminator itself, the design of the Microsoft Outlook for Mac output file format (.olm), the design of relevant standards formats .mbox, .ics and .vcf for email, calendar and contact information pose certain challenges and limitations to achieving ideal "loss-less-ness". Best efforts have been taken to work around these design and implementation challenges with Olminator in order to maximize retention of information from .olm file in the output files generated.
By default, Olminator converts .olm files using settings that optimize interoperability with Apple Mail, Apple Calendar and Apple Contacts. In order to do so, it applies certain restrictions or workarounds to the generated conversion output. If you do not want those restrictions or workarounds applied, you can change Olminator's default settings. See section Configuring Olminator for details.
If you run into any issues when importing conversion results, please also check the limitations imposed by the application into which you're importing. Apple, for example, has published limitations to their iCloud-based productivity apps that are worth considering (see Limits for iCloud Contacts, Calendars, Reminders, Bookmarks, and Maps).
There are no file size limitations for the input .olm file that Olminator can handle. The entire conversion is done in streaming mode, i.e. Olminator scans sequentually through the input provided and generates the corresponding output. It has successfully sifted through hundreds of gigabytes of .olm archive.
There are no major limitations on Email conversion in Olminator. In particular, there is no size limitation for an individual email, its attachments or the size of all emails converted in total.
In general all information exported by Microsoft Outlook for Mac regarding an email will be preserved in the conversion output (.mbox files). Known exceptions to this are the following topics:
An apparent limitation imposed by Apple Mail is a restriction to a maximum size of about 2 GB per individual .mbox file during import. It can import several .mbox files totalling more than 2GB in size though. So Olminator by default allows you to automatically split the conversion output into a series of individual .mbox files with a size below or around this 2 GB limitation. The files will either be labeled with a sequence number suffix in their filename or – which is the default setting – with a carefully crafted filename that will "trick" Apple Mail into re-merging all corresponding split files into a single folder as if they had all been in just a single .mbox file. You can decide which behaviour you prefer (sequential names that you may have to manually re-merge after the import if desired, or using the auto-merge naming "trick" to have Apple Mail do this for you automatically): Configuring Olminator contains more information about the respective configuration settings and their effects.
By default, Olminator splits .mbox files into separate smaller ones if a maximum size of 2GB is reached for an individual file. If you do not want this default behavior, uncheck the "Split output after [mb] MBytes:" option in the advanced configuration settings or change the maximum size specified according to your email client's needs/limitations. See section Configuring Olminator and Troubleshooting for more details.
Calendar information is converted into so-called "iCalendar" or ".ics" files following the standard described in RFC5545.
In general, there are no limitations imposed by Olminator during the conversion, i.e. all information is preserved in the conversion process. The conversion is hence loss-less.
Olminator converts individual events as well as recurring events with all Microsoft Outlook for Mac recurrence patterns, including modified and deleted individual occurrences of a recurring calendar event. Timezone information which was used for specifying start and end dates and times of calendar events is properly conserved and export dates given in UTC/Zulu times are converted correctly where needed.
As stated above, all information exported by Microsoft Outlook for Mac regarding calendar events will in general be preserved in the conversion output (.ics files). Known exceptions to this are only the following:
While standard RFC5545 provides sufficient flexibility to encode all relevant calendar information as exported by Microsoft Office for Mac, there are – at least at the writing of this – a number of limitations when importing the converted calendar .ics file into Apple Calendar. Besides the general size contraints on how big a single calendar can grow (whatever that size limit is, but it seems to exist), there appear to be the following limits in place with Apple Calendar:
Please be aware that Apple Calendar and "Microsoft Outlook for Mac" don't always support the same features, so you may not find everything you're used to in "Microsoft Outlook for Mac" calendars in Apple Calendar. So not everything you're missing is an issue of the Olminator conversion that was done with your calendar data, but a result of different application feature sets. I've taken utmost care to convert your calendar data in all its relevant aspects and tried to make sure it can be properly mapped to Apple Calendar or other calendar applications by sticking to the supported standards (RFC5545/iCal) and seeking proper workarounds when needed and possible.
Some heuristics in regards of recurrence day handling had to be applied by Olminator to preserve occurrences in a loss-less fashion: Microsoft Outlook for Mac allows to specify certain day patterns with recurring events (e.g. every Monday and Thursday each week). It also allows selecting "all days of a week", "weekdays" and "weekend days" as a logical choice. But what is a weekend actually: Saturday and Sunday, or is it Friday and Saturday? That of course depends where you are: In Israel, for example, a weekend is Friday and Saturday. Microsoft Outlook for Mac apparently always assumes it's a Saturday and Sunday. As does Apple Calendar luckily. So Olminator can shuffle that information accordingly in between. RFC5545 doesn't know weekdays or weekends explicitely.
Weeks always start with a Sunday, at least that's what Microsoft Outlook for Mac assumes for recurring events (e.g. important when a recurring event is always to start on the first weekday of a month). Whether you've changed the first day of a week to e.g. Monday in Outlook's preferences, does not change the scheduling or export behavior of Outlook at all. This behavior is maintained by Olminator in the conversion as we don't have any better insights from the data provided. The good news: When importing into Apple Calendar, the exact same scheduling is applied and the exact same event occurrences are created.
Outlook for Mac 2011 timezone limitations:, at least that's what Microsoft Outlook for Mac assumes for recurring events (e.g. important when a recurring event is always to start on the first weekday of a month). Whether you've changed the first day of a week to e.g. Monday in Outlook's preferences, does not change the scheduling or export behavior of Outlook at all. This behavior is maintained by Olminator in the conversion as we don't have any better insights from the data provided. The good news: When importing into Apple Calendar, the exact same scheduling is applied and the exact same event occurrences are created.
In general, there is no loss in information during the conversion. All data is preserved.
Contacts information is exchanged by using a standard format ("vCard 3.0" format, or .vcf file) which is following RFC6350 as a contact information exchange format. Unfortunately, the number of standardized fields available is quite limited and both Microsoft Outlook for Mac as well as e.g. Apple Contacts go beyond the standard in terms of contact fields/information made available to the user. Furthermore RFC6350 does not specify how to handle non-standard fields (which would have been convenient, sigh...). So convering an export of Microsoft Office for Mac contact information into a .vcf file requires Olminator to decide how to handle those "non-RFC6350" contact fields. Olminator takes the following approach:
Using the above approach guarantees that all fields from a contact in Microsoft Outlook for Mac will be written into the conversion output and can be imported into Apple Contacts (i.e. show up there for better or worse). Whether other Contacts applications are able to handle the non-standard fields, obviously depends on the particular application and its approach. By search-and-replaing field names in the conversion output accordingly for those applications, one might manually tweak the conversion output to be "maximally" imported into a Contact application.
Contact Groups in Microsoft Outlook for Mac are written into corresponding RFC6350-compliant "kind:group" entries listing the group members with their email addresses. While Apple Contacts can import such a "standard" entry, it does not recognize it as a contacts group but only handles it as a standard contact with a number of email addresses. There seems to be no way to import Contact Groups into Apple Contacts with the "Import" functionality provided. But using this conversion approach in Olminator at least guarantees that you do not loose the information contained in your Microsoft Outlook for Mac contact groups.
Categories in Microsoft Outlook for Mac are converted to a standard-compliant "Categories" attribute in the conversion, but since Apple Contacts does not support category information for contacts and since this information may nevertheless be relevant to you, it is also added as a special field (s. above) so that it shows up in Apple Calendar at least in text form and is not lost.
Photos attached to contact information in Microsoft Outlook for Mac are copied into the conversion output. It appears as if there's a size limit in place in Microsoft Outlook for Mac: If a photo/picture is too big (whatever that limit actually is?), Outlook does not export the entire information for that particular contact! So make sure to check your contact information for any "drop-outs" after importing into your alternative app. Also, Microsoft Outlook for Mac exports images in TIFF file format which creates very large photo sizes (often in the MBytes range); this is independent of what image format you originally attached to your contact in Microsoft Outlook! Since a number of contact management applications impose restrictions on the size of an individual photo per contact or the sum of all contact photo's stored (Apple Contacts, e.g., claims to have a limit of 224KByte per contact and 200MB for the total size of all contact's photos when using iCloud), promoting the TIFF photo as is into the .vcf output file does not make a lot of sense. Olminator therefore does the following:
In all cases, if any dropping or shrinking of a photo of a contact takes place, a warning will be issued into the Olminator_errors.log file so that you know there's something going on behind the scenes and can react accordingly.
As can be seen at Apple's support site, there are hard limitations on the size of photos that can be imported with contact cards when using iCloud: 224 kByte per photo. And the sum of all photos (and text) of vCards may not exceed 200 MB in total (see Limits for iCloud Contacts, Calendars, Reminders, Bookmarks, and Maps). I've therefore added an option to Olminator that allows you to drop photos from contacts during the conversion (either always or if they exceed a given size limit).
Support for CSV file export of contact data has been added as of v2.50. While CSV is a very common transfer format between applications for arbitrary data and enjoys broad support, it also comes with the downside of many "not-100%-standard-compliant" implementations, unclarity about character sets supported, etc.. You will not likely experience trouble converting contacts in Olminator to CSV, it may only become difficult when trying to import the CSV into certain applications.
Hint: If you're trying to load the CSV file into Microsoft Excel, please read the Configuration/Contacts section for details about overcoming potential issues with data import into Microsoft Excel.
Hint: Apple Numbers works just like a charm importing Olminator's CSV export.
Hint: For the nerds: Olminator uses UTF-8 encoding to write the CSV file. It writes a UTF-8 bytemark (xEF xBB xBF) to the beginning of the file which gets correctly honored by Apple Numbers and Microsoft Excel. Should your CSV processor complain over weird characters () at the beginning of the file, then that's that. Perhaps it works after removal.
As should be obvious from the above, Olminator works as information retaining and loss-less as possible, working around imposed limitations as much as possible.
Nevertheless it's probably advisable to point-check your data after importing it into your target applications to make sure all the information has been properly preserved and imported. We want to avoid bad surprises some time later as much as possible.
