Export Google Calendar to another Gmail account when you change address

Changing the address you actually use is easy everywhere except the calendar. Mail forwards. Contacts sync. Files are shared in a click. The calendar is the one place where years of appointments, recurring reviews and birthdays sit in an account that is about to go quiet, and where the obvious verb, export, turns out to describe a file rather than a move.

That distinction is the whole job. Exporting a Google Calendar to another Gmail account produces a snapshot: a file written at one moment, read into a second account, and independent from then on. Sometimes a snapshot is exactly right. Sometimes it is the wrong tool and a share would have solved the problem in thirty seconds. What follows separates the two, then walks the file route carefully enough that nothing gets lost in it.

Why export is the route between two personal addresses

The cleanest way to hand a Google Calendar to another account is not export at all. It is an ownership transfer, which keeps guest lists, history and sharing settings intact while a different account becomes the owner.

That route is closed for the case most people are in. Google's documentation states that the primary calendar, the one assigned automatically at first sign-in, cannot be transferred. Only secondary calendars can change hands, meaning calendars that were deliberately created, or a group calendar shared with the account. For an address change, the events that matter are almost always on the primary calendar, because that is where everything lands by default.

So the file route is not a workaround chosen out of ignorance. It is the only route available for a primary calendar, and knowing that in advance stops an hour of searching for a transfer button that does not exist for this case.

One deadline is worth naming now. Deleting a Google Account also deletes every calendar that account owns. Whatever is going to be exported has to be exported while the old account is still open, not after it has been closed.

There is a partial exception worth knowing, because it changes the plan for anyone who cares about guest lists. Events sitting on a project calendar rather than the primary one can be transferred properly, and so can individual events through the Change owner option. So a hybrid approach is available: transfer the handful of events that need their attendees intact, and export the rest as a file. That is more work than one export, and it is the only way to keep both the history and the invitations.

The export side, step by step

Export runs from a browser on a computer. Google states plainly that exporting is not possible from the Google Calendar app, so a phone will not finish this job.

Two prerequisites decide whether the option is even there. The account needs the "Make changes and manage sharing" permission on the calendar being exported, which is automatic for calendars the account owns and not automatic for calendars shared by someone else. And on a work or school account, an administrator may have restricted export settings entirely.

To take everything at once, open Google Calendar, go to Settings, choose Import & export, and click Export under the Export heading. A .zip file downloads containing one .ics file per calendar, including the ones subscribed to rather than owned.

To take a single calendar, find it under "My calendars" on the left, hover the name, open Settings and sharing, and click Export calendar under Calendar settings. That produces a single .ics file.

One documented failure belongs here. Pulling a calendar out through the public address in iCal format can return a "Feed processing error". Google's answer is to use the secret address in iCal format instead, and if no secret address is offered for that calendar, it cannot be exported by that method at all.

The import side, and the dropdown that decides everything

The import happens in the new account, from the same screen. Open Google Calendar, go to Settings, choose Import & export, click Select file from your computer, and pick the file. Google Calendar reads .ics and .csv on a computer.

Then comes the step that gets skipped. Before clicking Import, choose which calendar receives the events. The default destination is the primary calendar, so skipping this merges an old work calendar straight into the new personal one, where it is tedious to separate again. Creating an empty calendar in the destination account first, named after where the events came from, and importing into that, keeps the option of hiding or deleting the whole batch later.

A .zip file cannot be handed over as-is. It has to be unpacked, and each .ics inside imported one at a time. For an account with a primary calendar, two project calendars and three subscribed holiday feeds, that is six separate imports, and the subscribed ones are usually not worth importing since they can simply be subscribed to again.

If the source is a spreadsheet rather than Google Calendar, the formatting rules are strict. The header row must be written in English, with Subject and Start Date as the two required columns. Start Time, End Date, End Time, All Day Event, Description, Location and Private are optional. Any value containing a comma needs quotation marks around it. A file exported from a localised tool almost always needs its headers relabelled before Google Calendar will accept it.

What an .ics file does not carry

An import is not a clone, and the gaps are documented rather than mysterious. Google states that when an event is imported, guests and conference data for that event are not imported.

Read that slowly, because it decides how much manual work follows. Every attendee list is gone. Every accepted or declined response is gone. Every Google Meet or Zoom link attached to the event is gone. What arrives is the title, the time, the description and the location.

For a calendar of personal commitments, that loses almost nothing. For a calendar of client meetings, it is the difference between a handover and an archive of titles and times.

There is a practical way to keep the loss visible instead of discovering it later. Before exporting, search the old calendar for the events that carried guests, and note which of them still have future occurrences. Past meetings with no attendees attached are fine as an archive. Future meetings with attendees are the list that has to be rebuilt, and it is nearly always short: a handful of recurring reviews and standups rather than years of history. Writing that list down before the export turns an unbounded worry into ten minutes of re-inviting.

Recurring events have their own quirk. Google notes that repeat events imported from a .csv file may not appear as a series at all, arriving instead as a run of one-time events. An .ics file fares better, because the repeat rule travels as an RRULE property defined in the iCalendar standard, which Google Calendar reads natively. Where a series matters, use .ics rather than .csv.

Copying against sharing: pick before you export

The question underneath the search term is usually not how to export, but whether to.

	Export and import	Share the calendar
Events afterwards	Two independent copies	One set, seen from both accounts
Stays in sync	No	Yes
Guests and RSVPs	Not carried	Kept
Works if the old account closes	Yes	No
Works across organisations	Yes	Depends on admin policy
Effort later	Re-invite guests, fix drift	None

Google is direct about the sync question: imported events do not stay in sync between two accounts, and if the calendars need to match, the recommended answer is to share the calendar with the other account instead.

That reframes the decision. If the old account is being deleted, exporting is mandatory and the losses are the price of the move. If the old account will stay open, for example because one address is work and the other is personal and both will run for years, sharing is better on every line of that table. Many people export when they wanted to share, then spend months wondering why two calendars disagree.

Bringing the same file into a Mac or Outlook

The .ics file produced by the export is a standard format, so the destination does not have to be Gmail.

The Calendar app on a Mac imports one by choosing File, then Import, or by dragging the file into the window, then picking which calendar receives the events. Apple notes that importing a calendar file removes the event's previous custom colour. Apple's own archive format is different and dangerous to confuse: importing a calendar archive file replaces all current calendar information, which is a restore rather than a merge.

Outlook on the web takes the same file through Add calendar, then Upload from file, choosing a destination calendar before importing. Microsoft draws the same snapshot distinction Google does, and adds a number worth knowing if the calendar is subscribed to instead of imported: updates to a subscribed feed can take more than 24 hours to appear, although they typically arrive around every six hours.

The practical consequence is that a subscription is not a live mirror. It is a slow one. Anything that changes on the day it happens should not be depended on through a subscribed feed.

After the move, the old address keeps arriving

One task survives the export and nobody schedules it. Invitations already sent to the old address will keep landing there, because the guest list on someone else's event still holds the old string.

Three things are worth doing in the first week. Update the address on the recurring meetings that other people own, by asking the organiser rather than editing a copy. Check the calendars that were subscribed rather than owned, and resubscribe them in the new account instead of importing stale copies. And decide whether both accounts stay connected side by side, since the events that go missing after an address change are usually the ones sitting in an account nobody opens any more.

That last point is where the tooling matters more than the file format. A desktop calendar that connects several Google accounts at once, shows them together or one at a time, and lets a default account be chosen for new events, removes the pressure to consolidate everything into a single address. The Features page lists what that arrangement covers, the Guide walks through adding more than one account, and Compared with other calendars lines up what the alternatives cost over three years.

What to change first

Before exporting anything, answer one question: is the old account being closed, or just used less. If it stays open, share the calendar and skip the file entirely. If it is closing, export now while access remains, import into a freshly created calendar rather than the default one, and treat guest lists as work to redo rather than data to carry. To keep both addresses on one screen while that settles, Caltimate connects as many Google accounts as needed.