Event import and export not working: what to check, in order

A calendar export finished, the import screen accepted the file, and the calendar still looks wrong. Or the import refused the file with a one line message that explains very little. Either way, the natural reaction is to try again, and trying again is usually what makes things worse, because a second import on top of a partial first one leaves a mix of good events, missing events and duplicates.

Import and export failures are rarely random. They fall into a small number of causes, and each cause lives at a specific point in the journey: the source app, the file itself, the destination app, or what the destination quietly drops. Checking those points in that order is faster than retrying, and it leaves a clear record of what was actually wrong.

Before anything else: build a small test file

The single most useful habit is to stop moving the whole calendar until a small piece has made the trip successfully.

Export a short range, one week or one month, from the source calendar. Then create a new, empty calendar in the destination and import the small file into that calendar only. Apple's own instructions for importing on a Mac mention creating a new calendar first as an optional step, and it earns its place. If the test goes wrong, deleting that one calendar removes every imported event at once. Nothing already in the destination is touched.

The test file answers three questions in a couple of minutes:

• Do the times land at the right hour?
• Do repeating events stay as a series, or arrive as separate copies?
• Did the events go into the calendar that was chosen, or somewhere else?

If all three look right with a week of data, the full move is very likely to work the same way. If one of them is wrong, it will be wrong for thousands of events too, and it is far cheaper to discover that with seven.

Stage one: the source app produced the wrong thing

Many import problems are really export problems. The destination is being handed a file it was never going to accept.

Google Calendar

Google Calendar exports only from a computer. Its help pages say plainly that export is not available on a phone or tablet, so a missing export option in the mobile app is expected behavior.

Exporting a specific calendar also needs the right permission. Google requires "Make changes and manage sharing" access to export a calendar. A calendar someone shared with view access can be read on screen and still cannot be exported. Work and school accounts add another layer: an administrator can restrict export for the whole organization, and no personal setting overrides that.

Exporting everything produces a .zip file, not a calendar file. Inside are separate .ics files, one per calendar. Handing the .zip to another calendar app usually fails. Unzip it and import each .ics individually.

Apple Calendar on a Mac

Apple Calendar offers two different exports, and they are not interchangeable. Selecting one calendar and choosing File, then Export, then Export creates a .ics file. Choosing File, then Export, then Calendar Archive creates a .icbu file containing every calendar.

The .icbu archive is a restore format for Apple Calendar. Microsoft states that Outlook for Mac can only import iCal events saved in the .ics export format and cannot import the .icbu archive. If the goal is to move events anywhere other than back into Apple Calendar, export .ics.

Outlook for Mac

The legacy and new versions of Outlook for Mac behave differently here, which matters now that the old version is on its way out. Microsoft's article on importing into legacy Outlook for Mac notes that Outlook on the web, iCloud and Google calendars cannot be imported at this time. The feature list for the new Outlook for Mac shows that .ics attachments can be opened, exported and saved. Confirm which version is open before following any set of instructions.

Stage two: the file breaks a rule the destination enforces

If the export was correct, look at the file itself before importing again.

Google Calendar imports files of one megabyte (1MB) or smaller. A calendar with several years of history can exceed that. The fix Google suggests is to export a shorter date range from the original application, which in practice means splitting the history into several files by year.

Spreadsheet files have stricter rules. Google Calendar does not accept CSV files that use a semicolon or a colon to separate fields, so the separator must be a comma. The header row must use Google's English column names. Only Subject and Start Date are required, while Start Time, End Date, End Time, All Day Event, Description, Location and Private are optional. Some spreadsheet programs pick the separator from regional settings and can write semicolons instead of commas, which produces a format error even though the file looks fine when opened.

Google also notes that its importer is built around files created by major calendar applications, naming Microsoft Outlook, Apple Calendar and Yahoo Calendar. A file generated by a smaller service or a custom script can contain structures the importer does not recognise. When that happens, importing the file into one of those major apps first and exporting it again from there often produces something Google will read.

Stage three: read the error message literally

Google Calendar's import errors are short, but each one points at a specific cause documented in its troubleshooting page.

Message	Documented cause	What to do next
Processed zero events	Import was clicked more than once, and the first click already imported the file	Open the calendar and check whether the events are there
Processed x of y events	Some events in the file could not be read	Check which app created the file and re-export from a major calendar app
Google Calendar is temporarily unavailable	Usually the file is too large, or Import was clicked twice	Split the export into shorter date ranges
The connection to the server was reset	The file is not formatted correctly	Check CSV separators and headers, or the .ics header and footer

The first row deserves attention. "Processed zero events" looks like a failure, and the instinct is to import again from a different browser or with a renamed file. According to Google, that message usually means the job already succeeded. Look at the calendar before doing anything else.

The table above covers Google Calendar only. When the destination is Outlook.com or Apple Calendar, the test calendar from the first section does most of the diagnostic work: if a small file imports and a large one does not, the problem is size or a single malformed event in the larger range.

Stage four: the import worked, but the events are wrong

This is the stage where people most often conclude that import is broken. Usually it is behaving as documented, and the missing pieces were never going to travel.

Times are shifted

Google explains that events can appear at the wrong time when the time zone in Google Calendar does not match the time zone of the application that created the file. The fix is to align both settings, then export and import again. A shift that is an exact whole number of hours usually points here. Editing each event by hand is slower and still leaves the underlying mismatch in place for the next import.

Repeating events became separate copies

Google states that repeating events imported from a .csv file may appear as a series of one time events. It also notes that some applications export repeating events as a collection of single events even in their own format. If a weekly meeting arrives as dozens of unrelated copies, the source export is the place to fix it. Use .ics rather than CSV, and check whether the source app has an option that preserves recurrence.

Guests, meeting links and colors are gone

Google Calendar does not import guests or conference data. The event arrives with its title, time and description, but the attendee list and video meeting details stay behind. Apple Calendar has its own losses: importing a .ics file removes an event's previous custom color, and importing a calendar archive removes the custom colors of all calendars.

Changes made at the source never arrive

A common report is that the import worked on Monday, the source calendar was updated on Tuesday, and the destination never changed. That is not a sync failure, because nothing was syncing. Microsoft describes the distinction directly in its Outlook.com documentation:

When you import an .ics file, you get a snapshot of the events in the calendar at the time of import. Source: support.microsoft.com

Microsoft adds that imported events are not refreshed even when the calendar's owner makes an update. The alternative it offers is subscribing to the calendar by link, which does update, but on a delay: approximately every 3 hours in Outlook.com and every 6 hours in Outlook on the web, with a note that an update can take more than 24 hours. A subscribed calendar is maintained by its owner, so changes belong at the source. The choice is between a copy that can be edited locally but never updates, and a feed that updates on a delay and is changed where it originates. Knowing which one is in place explains most of the "it stopped updating" reports without any troubleshooting at all.

Events cannot be found

By default, Google imports into the primary calendar. If a different calendar was chosen, and that calendar is hidden in the sidebar, the import looks empty. Check the visibility of every calendar before assuming nothing arrived.

Stage five: undo safely, and do not overwrite by accident

Imported events are copies. They are not linked to the original, so there is no single command that removes only the events added by one import when they were mixed into an existing calendar. That is why the test calendar approach matters: if the imported events live in their own calendar, removing the calendar removes the import cleanly.

The larger risk on a Mac is the archive. Apple warns that importing a calendar archive file replaces all current calendar information and data. Someone who wanted to add old events to today's calendars and chose the .icbu file will instead roll every calendar back to the state it was in when the archive was made. When the intent is to add, import .ics.

There is also a timing issue worth planning around. Microsoft has announced that support for legacy Outlook for Mac ends in October 2026, and that Exchange Web Services in Exchange Online will be retired on October 1, 2026. Anyone moving calendar data out of the legacy client should do the export while that client still connects to the account, rather than after it stops.

Deciding what to change first

If an import failed outright, start with the file: unzip it, check its size against Google's 1MB limit, and confirm it is .ics rather than .icbu or a semicolon separated CSV. If the import succeeded but looks wrong, delete the imported calendar, fix the time zone or the export format at the source, and repeat the test with one week of events before moving the rest.

If the same export and import is being repeated every week to keep two calendars aligned, the problem is not the procedure. A file is a snapshot, and repeating it by hand will keep producing duplicates. Showing the accounts side by side in one app avoids the transfer altogether; Caltimate is built that way, and how Mac calendar apps compare sets out the alternatives.