Google Takeout to Immich: How to Migrate Photos

Migrating a Google Photos library to Immich is four steps: export the library with Google Takeout, stand the server up before the archives arrive, import with a Takeout-aware tool rather than copying files in, and verify the result before you delete anything from Google. The step people skip is the third one, and it is the one that quietly destroys years of dates, albums, and locations.

This is the failure mode worth understanding before you start, because it is silent. Nothing errors. The photos all arrive. They just land in your timeline dated the day you imported them.

Why a Plain File Copy Loses Your Metadata

Takeout does not always write your photo’s original timestamp, GPS coordinates, description, and album membership back into the image file’s EXIF. A large share of it is delivered in companion .json sidecar files sitting next to each image in the archive. Drag the folder of .jpg files into any photo server and the sidecars are ignored: the server falls back to the file modification date, which is the moment the archive was unpacked.

An import tool that understands Takeout reads those sidecars and applies the real values as it uploads. That is the entire difference between a migration and a mess, and it is why the Immich documentation points at a specific community tool for this job instead of its own generic uploader.

Step 1 — Order the Export

Go to Google Takeout and start by deselecting everything, then selecting Google Photos alone. A full-account export bundles in Drive, Mail, and everything else, which multiplies the download for no benefit. Photos also lets you narrow the export to specific albums if you only want part of the library.

Three settings on the export screen decide how painful the next day is:

• File type. .zip opens on any machine without extra software. .tgz is the alternative, and Google’s own guidance is that it may need additional software on Windows; on Linux or macOS it is a non-issue.
• Archive size. Takeout splits the export into parts at a size cap you choose, up to a documented maximum of 50 GB per archive, and anything above the cap arrives as multiple numbered parts. Larger parts mean fewer files to babysit; smaller parts mean a failed download costs you less. For a library of a few hundred gigabytes on a stable connection, the 50 GB option is the least work.
• Delivery. A download link by email is the default. Exporting straight into Drive, Dropbox, OneDrive, or Box is also offered, and sending the archives to cloud storage you already sync to the server can save a round trip through your laptop.

Then wait. Google’s documented range is anywhere from a few minutes to a few days, with most people getting the link the same day they ask; a multi-hundred-gigabyte photo library is exactly the case that lands at the slow end. Order the export the day before you plan to do the work, not the morning of.

Step 2 — Download Promptly and Check the Set

Takeout download links are time-limited: archives expire after roughly a week, and each one can be downloaded five times before you have to request the whole export again. Do not order a 400 GB export and go on holiday.

When the parts arrive, confirm you have every one of them before unpacking — they are numbered, and a missing part is a silent hole in the library rather than an error. Verify each archive opens cleanly. A truncated download that unpacks halfway is the second most common way a migration goes wrong.

Keep the original archives until the whole migration is verified. They are your rollback.

Step 3 — Stand Up Immich First

Have the server running and reachable before the import, not after. The requirements are modest but specific: 6 GB of RAM minimum with 8 GB recommended, 2 CPU cores minimum with 4 recommended, and a Postgres database that must sit on local SSD storage rather than any kind of network share. The library itself can live on bulk storage mounted into the container.

If you have not built it yet, Immich vs Google Photos covers what the stack contains and what it asks of a host, and the self-hosted app picker and resource budget estimator will tell you whether it fits alongside whatever else you already run before you commit to the move.

One sizing note that catches people out: during a large import the server is doing thumbnail generation and machine-learning indexing on top of receiving uploads. A first import of tens of thousands of assets can keep a modest CPU busy for many hours after the transfer itself finishes. That is normal, it happens once, and it is not a reason to buy a bigger box.

Step 4 — Import With a Takeout-Aware Tool

Immich ships an official CLI (npm i -g @immich/cli, or a Docker image if Node is unavailable). It is a good uploader for ordinary folders — immich upload --recursive directory/, with --album to create albums from folder names, --dry-run to preview, and --ignore for glob patterns you want skipped. But for a Google Photos export the documentation explicitly recommends the community-maintained immich-go instead, because it is built to match photos with their JSON metadata.

immich-go is a single binary — no Node, no Docker — with builds for Linux, macOS, Windows, and FreeBSD, and it takes the Takeout archives directly:

immich-go upload from-google-photos \
  --server=http://your-server-ip:2283 \
  --api-key=your-api-key \
  /path/to/takeout-*.zip

Generate the API key from your Immich user settings first. Points worth knowing before the run:

• It reads the archives as-is. You do not have to unpack the zips, which saves an entire copy of the library’s worth of disk space.
• Albums, descriptions, and locations are reconstructed from the sidecar JSON rather than guessed from filenames.
• Duplicates are detected, so a re-run after an interrupted import does not double your library.
• RAW+JPEG pairs and bursts are stacked rather than cluttering the timeline as separate assets.
• Junk is skipped by default. The tool ships with sensible exclusions for NAS and OS clutter such as @eaDir/, SYNOFILE_THUMB_*, .DS_Store, .Spotlight-V100/, and Recently Deleted/, and --ban-file adds your own patterns.
• It is honest about its own status. The project describes itself as an early version and tells you to keep a backup copy of your files. Keep the archives.

Run it against a single small archive first and look at the result in the web app before turning it loose on the whole set.

Step 5 — Verify Before You Delete Anything

Count the media in the export rather than eyeballing it. Without unpacking anything:

for z in takeout-*.zip; do unzip -l "$z"; done \
  | grep -ciE '\.(jpg|jpeg|heic|png|gif|mp4|mov)$'

Compare that against the asset count Immich reports on the server once indexing has settled. The two will rarely match exactly — the archives also carry .json sidecars and other non-media artifacts, and the importer skips its default junk list — but they should be close, and a gap of thousands means something went wrong.

Then spot-check the things that break silently:

• Dates. Open the oldest photos you own. If the timeline puts your 2009 holiday in the current month, the sidecars were not read and the import needs redoing.
• Albums. Confirm a handful of albums exist with roughly the right contents.
• Locations. Open the map view. A library with GPS data should light up; an empty map means metadata was lost.
• Motion photos and live photos. These arrive as paired files and are the fiddliest category. Check that a few play rather than showing as stills plus orphan video clips.
• Edited versions. Google stores an edited copy alongside the original for photos you have retouched. Decide whether you want both, and check which one landed in the timeline.

Step 6 — Do Not Delete From Google Yet

The last step is the one to be slow about. Until the library exists in at least two places you control, Google is still your off-site backup, and it is doing that job for free while you decide.

Get a real 3-2-1 backup strategy running first, covering both the photo files and a dump of the Immich Postgres database — the database is where albums, faces, and everything the import just reconstructed actually lives. Restore a test file from that backup and confirm it opens. Only then consider clearing the Google copy, and even then, keeping the original Takeout archives on a cold external disk costs almost nothing.

Then Switch On Phone Backup

Once the historical library is in and verified, open the Immich mobile app, choose the device albums you want covered on the backup screen, and enable backup. From that point the server is the destination for new photos and Google is out of the loop.

If you are still weighing whether Immich is the right destination at all, the head-to-head of self-hosted Google Photos alternatives compares it against Ente, PhotoPrism, Nextcloud Memories, and LibrePhotos — and if you already run Nextcloud, for instance on a Raspberry Pi, the Memories app is a lighter destination for the same export.