Apple Calendar export: taking your events with you off the Mac

Most people reach for an Apple Calendar export at an awkward moment. A Mac is being replaced, a work account is being closed, a calendar needs to move into Google, or six years of events need to exist somewhere that is not a single machine. The Calendar app has the commands for all of this, but they sit in two different places under the same menu, they produce two different file types, and only one of them can destroy what is already on the Mac when it is imported back. Knowing which is which before clicking is the whole job.

Two commands, two very different files

Calendar on the Mac exposes exactly two export routes, both under the File menu.

To export a single calendar, select that calendar's name in the calendar list first, then choose File > Export > Export, pick a location, and click Export. The result is a calendar file with the .ics extension, holding the events of that one calendar.

To export everything at once, choose File > Export > Calendar Archive, pick a location, and click Save. The result is a calendar archive with the .icbu extension.

The selection step in the first route is the part that gets skipped. If the wrong calendar is highlighted in the sidebar, the export runs anyway and produces a file full of the wrong events, with no warning and no obvious sign in the filename. Checking the sidebar highlight before opening the File menu costs a second and saves a confusing afternoon.

The two formats are not interchangeable. An .ics file is a portable calendar file that almost every calendar service on any platform can read. An .icbu archive is Apple's own container for the whole Calendar database, and it behaves like a backup rather than like a document. Anything that needs to leave the Apple world needs the first one.

Why the archive is a restore, not a merge

The archive route has a consequence that the single calendar route does not, and it is stated plainly in Apple's own documentation for the Calendar app: importing a calendar archive file replaces all of your current calendar information and data.

Replaces. Not adds to. If a Mac has picked up new events since the archive was made, importing that archive puts the Mac back to the state it was in when the archive was written, and the newer events are gone. The archive is the right tool for moving a whole calendar setup to a fresh Mac, or for holding a point in time before a risky account change. It is the wrong tool for merging two machines, and it is a bad habit to use casually.

Importing a plain calendar file behaves the opposite way. Drag the file into Calendar, or choose File > Import, select the file, click Import, then choose which calendar receives the events. Nothing else on the Mac is touched. Because the destination is chosen at import time, the usual practice is to create an empty calendar first, import into that, and inspect the result before letting it mix with anything that matters.

Both import routes drop the custom event colors that were set by hand. A single calendar file import removes the imported event's previous custom color. An archive import removes the custom colors on all calendars. If color is carrying meaning in a workflow, it is carrying meaning that will not survive the trip, and a note somewhere outside the calendar is worth writing before the move.

Where the .ics file can go next

The reason to prefer .ics is that it is accepted on the receiving end. Google Calendar imports both ICS and CSV files on a computer, through Settings, then Import & export, then Import, with a destination calendar chosen before the import runs.

Two details of that route are worth knowing in advance, because both change the plan.

First, a Google Calendar export does not come out as a single file. It downloads as a .zip archive containing one .ics file per calendar, and Google's instructions are to open the zip and import each .ics file individually. An Apple Calendar archive has the same one-to-many shape in spirit, so anyone moving a dozen calendars is going to be doing a dozen imports rather than one.

Second, and more important: when an event is imported into Google Calendar, guests and conference data for that event are not imported. That single sentence changes what an export actually is. The dates, titles, times, locations and notes travel. The attendee list does not. Neither does the video meeting link attached to the event. A calendar full of recurring meetings arrives on the other side as a calendar full of appointments with nobody in them.

For an archive of the past, that is usually acceptable. For a live working calendar, it is the difference between a migration and a broken week, and the better answer is often to connect both accounts to one app and let the accounts stay where they are.

There is also a case where the Mac is the wrong place to start. If the events being chased actually live in a Google account rather than in iCloud, exporting from Google directly is cleaner than exporting the mirrored copy out of Calendar. That route runs through Settings, then Import & export, then Export under the Export heading, and a zip file downloads. Two conditions apply to it. The account needs the permission to make changes and manage sharing on the calendar being exported, which rules out a calendar that was only shared for viewing. And an administrator on a work or school account can restrict export settings, which means the command can be absent through policy rather than through error. Establishing which account really owns the events, before opening any menu, avoids exporting a copy and thinking it was the original.

Getting from .ics to a spreadsheet

A large share of export requests are really requests for a spreadsheet. Someone needs billable hours, a record of client meetings, or a year of events in rows and columns. Apple's Calendar app does not offer a CSV command. Its export menu offers the calendar file and the calendar archive, and nothing else.

That is less of a dead end than it looks, because .ics is a plain text format with a published specification. The format is iCalendar, defined in RFC 5545, and its contents are readable in any text editor. Each event is a VEVENT block with labelled lines inside it, so a title, a start, an end and a location are all sitting there as text on their own lines.

The specification is also where the attachment question gets answered. RFC 5545 defines an ATTACH property whose default value type is a URI, with the option of inline binary content, and it can appear more than once inside a single VEVENT. In other words a file reference can legally travel inside an exported calendar file. Whether the app on the receiving end shows it is a separate matter, and the safe assumption is that a linked document stays behind unless it is checked on the other side.

Two practical routes exist for the spreadsheet case. A conversion tool reads the .ics and writes a CSV, which is quick but means handing a calendar to a third party. Or the CSV is built from the text directly, which keeps the data on the Mac. Neither route is part of Calendar itself, so budget for it rather than hunting the menus for a command that is not there.

Which route fits which reason

Reason for exporting	Route	File	Watch out for
Move one calendar into Google or Outlook	File > Export > Export	.ics	Guests and meeting links do not import
Move a whole setup to a new Mac	File > Export > Calendar Archive	.icbu	Importing it replaces everything present
Keep a point-in-time backup	File > Export > Calendar Archive	.icbu	Only useful on a Mac, custom colors are dropped
Produce rows for billing or review	File > Export > Export, then convert	.ics then CSV	No CSV command exists in Calendar
Hand a single event or trip to someone	File > Export > Export on a dedicated calendar	.ics	Put the events in their own calendar first

The table is doing one job: separating the backup case from the migration case. Those two get conflated constantly, and the archive is only correct for the first.

The check that is worth doing before deleting anything

An export that has never been opened is not a backup. Before wiping an account or handing back a machine, open the exported file and confirm the events are actually inside it.

For an .ics file, opening it in a text editor and searching for the title of the oldest event and the title of the newest one settles the question in under a minute. A file that covers this month but stops before last year is a sign that the wrong calendar was selected in the sidebar, or that the calendar in question was a subscription rather than a calendar of its own. Subscribed calendars such as public holiday feeds are read from a remote address, and exporting them produces something far less useful than a live subscription would be on the new machine.

For an .icbu archive, the file size is the cheap signal. An archive that covers years of events is not a few kilobytes. Anything suspiciously small deserves a second run.

Both checks matter more than they sound, because the failure they catch is silent. Calendar does not report that a calendar was empty, only that the export finished.

Stop treating the export as the plan

Exporting is worth doing, and it is worth doing before any account change rather than during one. What it cannot do is carry a working week across a gap, because the guest list and the meeting links are exactly what a working week is made of.

If the real problem is that events live in several accounts and none of them show the whole picture, the export is a symptom rather than a fix. A Mac calendar that holds several accounts at once removes the reason to move events between them, and the comparison of full featured Mac calendars lays out which apps read multiple accounts natively and which ones only mirror one. The feature list is the faster way to check whether a given account type is read directly.

What to change first

Run the single calendar export once on the calendar that matters most, open the file, and confirm the oldest event is inside it. Then decide whether the goal is a backup, which the archive handles, or a move, which the archive will not handle well. If the goal turns out to be seeing several accounts in one place rather than moving events at all, Caltimate covers that case on the Mac without an export step.