Export an Outlook calendar to iCal and open it on a Mac

The task sounds like one command. Export an Outlook calendar to iCal, open the file on the Mac, done. In practice the command exists in one version of Outlook, is missing from another, and has been replaced by something different again in the web client. Which version is on the desk decides the whole procedure, and the file that comes out carries less than most people expect.

What follows separates the three routes out of Outlook, says what each one produces, and then covers the part that actually causes trouble, which is what happens after the file reaches Apple Calendar.

What iCal means here, and what the file is

Two different things travel under the name. The Mac application Apple once called iCal now ships as Calendar, and people still search for the old name. The file format is separate: iCalendar, standardised as RFC 5545 in September 2009, saved with an .ics extension. Outlook, Google Calendar, Apple Calendar and almost everything else read and write it.

Knowing one detail of the format explains several later surprises. Inside the file, each event is a block of plain text lines. The standard says lines "SHOULD NOT be longer than 75 octets, excluding the line break", and longer lines are split with a technique called folding, where a line break plus a single space continues the previous line. That is why opening an .ics in a text editor shows long descriptions broken across lines at odd points, and why a naive spreadsheet import mangles them.

The other detail worth carrying is how the format marks the end of something. RFC 5545 states that the DTEND property "specifies the non-inclusive end of the event". The standard's own example of a festival running from 28 June to 8 July sets DTEND to 9 July. Multi-day events therefore arrive looking one day longer than they read, which matters the moment anyone counts days from the exported file.

The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. Source: rfc-editor.org

Three routes out, and which one is available

Microsoft documents three distinct ways to get calendar data out, and they do not produce the same thing.

Classic Outlook on Windows has a direct save to .ics. Open the Calendar, select the calendar, then File and Save Calendar. Microsoft's steps name a File name box for the iCalendar file, a More Options button, a Date Range arrow with a Specify dates option for a custom range, and a Detail arrow for how much of each event to include. Microsoft also warns that choosing a wide range or Whole calendar can produce a large file that takes a while to generate.

Legacy Outlook for Mac has no equivalent. Its export command lives on the Tools tab and writes an Outlook for Mac Data File with an .olm extension. Microsoft is explicit about the limit: "The only export option available at this time is the .olm archive file." An .olm goes back into Outlook and nowhere else, so it is a backup, not a handover. That page also carries a deadline worth knowing: support for legacy Outlook for Mac ends in October 2026.

Outlook.com and Outlook on the web publish instead of exporting. Under Settings, then Calendar, then Shared calendars, the Publish a calendar section offers an HTML link or an ICS link, with a choice of how much detail is visible. Microsoft notes that "HTML and ICS calendars are read-only" and that "How often your ICS calendar syncs depends on the recipient's email provider."

Route	Produces	Reads back into	Updates after the fact
Classic Outlook, File then Save Calendar	.ics file, chosen date range and detail	Apple Calendar, Google Calendar, most apps	No, it is a snapshot
Legacy Outlook for Mac, Tools then Export	.olm archive	Outlook only	No
Outlook.com, Publish a calendar	ICS link or HTML link, read only	Apple Calendar, Google Calendar by subscription	Yes, on the subscriber's refresh schedule
Outlook.com, Share calendar	Invitation, not a file	Outlook.com or Microsoft 365 accounts	Yes

The fourth row is the one people miss. Sharing and publishing are different features. Microsoft's sharing options are named "Can view all details" and "Can edit", and the same page warns that when a calendar is shared with someone who is not on Outlook.com, "they will only be able to accept the invitation using an Outlook.com or an Microsoft 365 account." A Gmail address cannot accept a share, but it can subscribe to a published ICS link.

Landing the file in Apple Calendar

Apple's Calendar has two import paths and they behave very differently. File, then Import, brings in a calendar (.ics) file and adds those events. Dragging the file onto Calendar does the same thing. The second path, importing a Calendar archive (.icbu) file, comes with Apple's own warning that it "replaces all of your current calendar information and data". An archive is for restoring a Mac, never for merging a colleague's calendar into an existing one.

Two smaller behaviours are worth expecting. Apple notes that importing a calendar file removes the event's previous custom colour, so a colour coded Outlook calendar arrives flat and has to be coloured per calendar rather than per event. And export in the other direction mirrors the import: File, Export, Export writes a single calendar as .ics, while File, Export, Calendar Archive writes everything as .icbu.

Before importing anything large, make the exported calendar its own calendar in the sidebar rather than dropping it into an existing one. Apple Calendar can create an empty local calendar in a few seconds, and importing into it keeps the incoming events separable. If the date range was wrong, or the detail level stripped the descriptions, deleting one calendar undoes the whole import. Merged into a calendar that already holds two years of personal events, the same mistake has to be unpicked event by event, and there is no undo once the sidebar has been rebuilt.

Where the events land is the choice that causes the most cleanup later. Importing into an iCloud calendar puts them on every device signed into that account. Importing into an On My Mac calendar keeps them on one machine and out of every phone. Neither is wrong, but picking by accident means discovering months later that a year of meetings exists on exactly one laptop.

What the snapshot does not carry

Microsoft states the central limitation plainly for the Google Calendar case: "you're exporting a snapshot of the calendar. Any changes you make to your Outlook calendar won't automatically be reflected in Google Calendar." The same is true of any .ics import. The file is a photograph of a date range.

Google's import documentation adds a second loss. When events are imported, "guests and conference data for that event are not imported". A meeting arrives with its title, time and place, and without the eight people who were invited or the link they were supposed to join. For a personal calendar that is fine. For a handover of a shared team calendar it is a serious gap, and it is the reason a published link beats a file whenever the calendar is still in use.

Privacy markings are a third. On the Outlook.com side, Microsoft notes that items marked private are protected and that most people with whom a calendar is shared "see only the time of items marked private, not the title, location, or other details", with recurring private series still showing their pattern. The Detail setting in the classic Save Calendar dialog does the equivalent job for a file, which means an export made at the wrong detail level either leaks more than intended or arrives as a wall of anonymous blocks.

Free and busy status survives, quietly. RFC 5545 defines a TRANSP property whose default is OPAQUE, meaning the event blocks time on availability searches, with TRANSPARENT for events that do not. Events deliberately marked as not blocking time keep that marking through the export, so a calendar that looked comfortably full in Outlook can look surprisingly empty to a scheduling tool afterwards.

A published link instead of a file

For any calendar that is still changing, the ICS link is the better answer, and the tradeoff is latency. Microsoft's figures for subscribed calendars in its own clients are approximately every three hours for Outlook.com and approximately every six hours for Outlook on the web, and the page adds that an update "can take more than 24 hours". Apple Calendar and Google Calendar run their own refresh schedules for subscribed URLs. Nobody publishes a subscription that updates in seconds.

That latency is acceptable for a calendar of fixed dates, such as a term timetable, a shift roster or a release schedule. It is not acceptable for a calendar where a meeting can move an hour before it starts. The honest rule is that a subscription is for reading someone else's fixed plans, a real account connection is for a calendar being actively negotiated, and a one-time .ics file is for archiving or for moving off a system being shut down.

If the goal is the last of those, do the export while the account still works. An .olm from legacy Outlook for Mac is only readable by Outlook, so anyone planning around the October 2026 end of support for that client needs the data out in .ics form, which in practice means doing it from the web client or from a Windows machine before the old application stops being an option.

The part no export fixes

An imported calendar is accurate and still unusable, for reasons the file format has nothing to do with. Four meetings arrive on one afternoon, each correct, with nothing between them, in three different parts of the city. The .ics carried every field Outlook had. It did not carry the forty minutes each of those transitions takes, because Outlook never held that information either.

This is where the choice of Mac calendar starts to matter more than the choice of export route. A native Mac calendar that treats travel as a real block, calculated from the addresses already in the events, turns an imported schedule into something that can be checked against the clock. How that calculation is presented, and how it behaves for driving, walking and public transport, is set out in Travel time, and the wider set of behaviours a desktop calendar can add on top of a synced Google account is listed under Features.

The second recurring problem after an import is entry speed. A calendar rebuilt from a file is only correct for as long as the next fifty events get entered properly, and typing a meeting into six separate fields is where most calendars quietly rot.

What to change first

Identify which Outlook is actually in front of you before anything else, because that single fact decides whether an .ics is available at all. Then choose deliberately between a file and a published link, on the basis of whether the calendar is finished or still moving.

Once the events are on the Mac, the remaining question is what puts the next ones in. Caltimate is built for that half of the job, keeping a Google account as the source of truth while handling entry and travel on the desktop.