Event import and export: how to decide what you need

"Export the calendar and import it over there" sounds like one instruction. In practice it hides a choice between half a dozen formats and routes: a single .ics file, a zip of .ics files, a Calendar Archive from a Mac, a CSV built in a spreadsheet, a data download from Google, or no file at all and a link instead. Each one carries different details, and only some of them keep up with changes after the move.

Picking the wrong one rarely fails loudly. The import says it succeeded, and the damage shows up weeks later as a meeting with no attendees, a repeating event split into fifty single ones, or a schedule that stopped updating on the day it was copied. This guide sets out five questions that narrow the choice before any file is created.

Files and links: the two families

Almost everything in this area rests on iCalendar, the open format defined in RFC 5545. The standard's abstract describes it as a format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries and free/busy information, independent of any particular calendar service or protocol. That independence is why a file from one vendor usually opens in another.

On top of that format, the options fall into two families.

Files, which are copies:

• A single .ics file per calendar. Google Calendar offers this per calendar in its settings; Calendar on Mac offers it under File, Export, Export.
• A .zip of .ics files. Google Calendar produces this from Settings, Import & export, when everything is exported at once.
• A Calendar Archive (.icbu). Calendar on Mac produces this under File, Export, Calendar Archive.
• A CSV file. Built in a spreadsheet and imported, for example into Google Calendar.
• A Google data download, which delivers Calendar data in iCalendar format.

Links, which are connections:

• Google Calendar's "Secret address in iCal format".
• The public address of a published calendar.
• A calendar published from Outlook.com.

The rest of the decision is about which family fits, and then which member of it.

Question one: will the events change after they move?

This question splits the two families cleanly. A file is a snapshot. Microsoft's support article on Outlook.com states it directly: importing an .ics file gives a snapshot of the events at the time of import, and the calendar does not refresh them even if the owner makes an update. Microsoft suggests import for things that are not going to change, naming tide tables and phases of the moon, and subscription for things that change often, naming movie times and school calendars.

That framing translates into a short rule:

• Settled events, such as a finished project's history or a year of public holidays, can move as a file.
• Living events, such as a team rota, a club's fixture list, or a partner's working days, belong on a link.
• A second account of one's own needs neither. Sharing or adding the account to the app keeps a single original.

Links are not instant, so timing is part of the answer. Microsoft says Outlook.com subscriptions update roughly every 3 hours for personal accounts and roughly every 6 hours for work or school accounts in Outlook on the web, and can take more than 24 hours. Calendar on Mac asks for an Auto-refresh interval when a subscription is created. If something changes several times on the day itself, a link will lag behind it too, and a direct message remains the only reliable channel.

Question two: which details have to survive?

Once the family is clear, the details decide the member. Title and time are carried by everything. The rest is not.

Format or route	Details confirmed to carry	Details documented as lost or changed
CSV into Google Calendar	Subject, Start Date, Start Time, End Date, End Time, All Day Event, Description, Location, Private	Recurring events may arrive as a series of single events
.ics into Google Calendar	Event content	Guests and conference data are not imported
.ics into Calendar on Mac	Event content	Custom event colors are removed
Google data download	Start and end times, recurrence data, invitees and response statuses, title, description, location, creation and last modified times	Whether the destination can use all of it depends on the destination

Two things stand out. CSV carries a fixed set of columns and struggles with recurrence, so it is the weakest way to move existing events. It is also the strongest way to create events that do not exist yet, because a spreadsheet can produce a hundred rows in minutes. Google requires English headers and treats only Subject and Start Date as mandatory.

The second point concerns records. If the goal is proof of who was invited and how they replied, only the data download lists invitees and response statuses. Keeping a record and reusing data in another service are different goals, and the download is built for the first.

Question three: can the source actually produce it?

A format that the source cannot export is not an option, however well it fits the first two questions.

Google Calendar

• Export works only on a computer, not in the mobile apps.
• The calendar being exported requires "Make changes and manage sharing" permission.
• Administrators of work or school accounts may restrict export settings.
• Exporting everything yields a zip, and re-importing means opening it and importing each .ics file separately.

The permission rule catches people with shared calendars. A colleague's calendar shared with "See event details" is fully visible on screen, yet by Google's stated requirement it is not exportable. Anyone who needs a record of it must ask the owner to export it or to raise the permission.

Google's data download has its own limit: its help notes that on work or school accounts some data might not be available.

Calendar on Mac

A single calendar exports as .ics; all calendars together export only as a Calendar Archive. Apple's guide warns that importing an archive replaces all current calendar information and data. That makes the archive a restore point for the same Mac setup, not a vehicle for moving to another service.

Outlook.com

Microsoft's import and export overview lists contacts under export from Outlook.com. For the calendar, the same page points to sharing or publishing. In practice, the Outlook.com side of any plan is a link rather than a file.

Question four: will the destination accept it?

The destination sets its own terms.

• Google Calendar accepts .ics and .csv files of 1MB or smaller. Its troubleshooting page says it works with files made by major calendar applications such as Microsoft Outlook, Apple Calendar and Yahoo Calendar. Without a chosen destination calendar, events go to the primary calendar.
• Calendar on Mac accepts an .ics file dragged onto the window or opened through File, Import, and asks which calendar should receive the events.
• Outlook.com imports an .ics file into an existing calendar, or subscribes to a calendar by URL.
• iCloud caps calendars, events and reminders at 50,000 in total, and a single event at 20MB including attachments.

The 1MB limit is the one that reshapes plans. Years of history rarely fit in one file, so a long-lived calendar should be exported by date range or split by calendar from the outset.

One habit makes every destination safer: create an empty calendar first and import into it. Mixed into an existing calendar, imported events are hard to remove as a group if something looks wrong. In their own calendar, they can be checked, hidden, or deleted in one action.

Question five: who ends up holding a copy?

Event titles contain client names, interview candidates and home addresses. The route determines who keeps them.

• A file stays with whoever received it, permanently. There is no recall.
• A secret address lets anyone who has it read the calendar. Google says not to share it and offers Reset to invalidate it.
• A public address assumes anyone can open it. Only a calendar created for publishing, holding nothing private, should use it.

When sending a schedule outside the organization, a file feels simplest and is the hardest to undo. If access may need to end later, use sharing or a link. If only part of the schedule should be visible, create a separate calendar for that part.

Worked choices

Situation	Will it change?	What must survive	Best fit
A freelancer closes a client account and wants a record	No	Invitees and replies	Google data download
Moving from one calendar service to another	Managed in the new place afterwards	Titles, times, recurrence	Per-calendar .ics into an empty calendar
Loading a conference programme from a spreadsheet	No	Title, time, room	CSV
Publishing a club's fixture list	Yes	Title, time	Link to a dedicated public calendar
Reading a work calendar from a personal account	Yes	Full details	Sharing or adding the account
Backing up On My Mac calendars	No	Everything	Per-calendar .ics or a Calendar Archive

Two of these rows deserve a closer look, because they are the ones most often handled with the wrong tool.

The freelancer closing a client account tends to reach for the ordinary export, because it is the first option in settings. That export is built for moving events into another calendar, and Google's import help already states that guests and conference data do not come across on import. The data download is the route that explicitly lists invitees and their responses. It is worth doing before access to the account ends, since a work account's administrator controls what remains downloadable afterwards.

The move between services tends to go wrong in the opposite direction: everything is exported at once, as a zip or an archive, because it feels complete. A zip from Google has to be unpacked and imported file by file anyway, and a Mac archive is not meant for another service at all. Exporting calendar by calendar looks slower but gives natural checkpoints. Each calendar lands in its own empty destination calendar, gets checked against the original for recurring events and all-day events, and only then does the next one move. If the 1MB limit bites, the problem is confined to one calendar rather than the whole migration.

When the answers disagree

Sometimes the questions point in different directions. A recurring client meeting will keep changing, which argues for a link, while the history of invitations and replies should be preserved, which argues for a download. Trying to make one route do both usually ends with neither done well. Split the job: connect the future with sharing or a link, and take a one-off download of the past.

When a ranking is needed, put question five first and question one second. A file in the wrong hands cannot be taken back. A wrong format only costs a second attempt. Questions three and four then act as checks on whatever the first two allowed.

After the move, two chores remain whatever route was chosen. More calendars appear on screen, from subscriptions, import calendars and shares, and each day has to be read across all of them. Compared with other calendars lays out how calendar apps for Mac handle several accounts on one screen. And a handful of new events, too few for a CSV, still has to be typed in. Entering events describes creating an event from one sentence with the time, place and target calendar in it.

What to change first

Before the next export, answer question five and question one in a single line each: who will hold the result, and will the events change. That leaves at most two candidates. If the outcome is more accounts on screen than is comfortable, Caltimate is one desktop calendar that shows them together.