Budget two weekends, most of it waiting: Google Takeout needs one to three days to build your archive, immich-go imports it overnight, and the mobile app takes over backup from there. A four-core box with 8GB RAM and an SSD runs Immich comfortably for a six-figure photo library, and it replaces a Google One 2TB plan ($99.99/year) with hardware that pays for itself in under two years. The hands-on work is maybe six hours. Below is where those hours actually go, and the three places migrations go wrong.
Sizing a server for Immich
| Library size | RAM | Storage rule of thumb | First ML index (CPU, estimate) |
|---|---|---|---|
| 25,000 assets | 6GB works, 8GB comfortable | Originals + ~10% | Overnight |
| 100,000 assets | 8GB | Originals + ~10–15% | 1–2 days |
| 500,000 assets | 16GB | Originals + ~15% | Days; borrow a GPU |
The hungry parts are Postgres and the machine-learning container, not the web app. Put the database and generated thumbnails on SSD; originals can live on a spinning disk without anyone noticing. Immich stores your originals untouched and generates previews alongside, so the overhead above is thumbnails plus database — not a second copy of everything. Any iGPU or old GTX card cuts the ML indexing time dramatically, but it's a one-time cost; CPU-only is fine if you can wait a day. If you already have decades of photos organised in folders, note that Immich's external library feature indexes them in place, read-only — you don't have to re-upload an archive you've curated for twenty years just to search it.
The Takeout dance, done correctly
Request the export at takeout.google.com with only Google Photos selected, and pick 50GB archives so a 300GB library arrives as six files instead of a hundred and fifty. Then the part everyone gets wrong: Takeout scatters critical metadata — capture dates, GPS, favourites, album membership — into JSON sidecar files next to the images. Unzip everything and drag it into the web uploader and you'll get thousands of photos "taken" on migration day.
Use immich-go instead. It reads the zip files directly (no unpacking), re-merges the JSON sidecars, skips duplicates, and recreates your albums:
immich-go upload from-google-photos \
--server https://photos.example.com \
--api-key <your-key> \
~/takeout/takeout-*.zipAfterwards, verify before you celebrate: spot-check 20 photos across different years for correct dates and locations, and compare asset counts. The numbers won't match Google's exactly — motion-photo video halves, old Hangouts attachments, and trashed items account for the gap — but a 2% discrepancy is normal where a 20% one means a failed batch worth re-running. The wider service-by-service picture is in our Google Photos alternatives rundown.
The ML features are the point, not a gimmick
Smart search runs a CLIP model locally: "red kayak on a lake" and "kids in snow" both work, with zero cloud calls. Face recognition clusters people for you to name; duplicate detection catches the re-saves and WhatsApp copies Google happily double-counted. Expect roughly 5–10 assets/second during the first index on a modern CPU and a 2–4GB RAM spike while it runs — schedule it overnight and don't panic at the load average. After the initial pass, indexing new photos is imperceptible.
Mobile backup: the honest assessment
Android background backup is reliable — set it, forget it. iOS is where expectations need managing: Apple's background execution limits mean the Immich app backs up when opened and in the occasional background window iOS grants it, not continuously. The practical fix is a habit: open the app while your morning coffee brews and it stays current. First upload of a 40GB camera roll takes an evening on Wi-Fi, so plug the phone in. Leave "delete originals from device" alone until you've confirmed the server copy exists and is itself backed up.
What you give up
Less than you'd think, but not nothing. Sharing with non-technical relatives becomes public share links or a partner account rather than Google's one-tap sharing. Editing is crop-rotate-adjust — no magic eraser, no generative fill; keep doing that on the phone before backup. Memories ("3 years ago today") and a GPS map view exist in Immich and work well. Printing integrations don't. If your household lives inside shared Google albums with comments, run both systems in parallel for a month and see what you actually miss before cancelling anything.
Immich is not a backup
This is the mistake that costs people their photo library: a single-server Immich is one disk failure from gone, which is a worse position than Google. Treat it as tier one of a 3-2-1 backup plan from day one — nightly database dump plus the originals directory to a second disk, replicated off-site. The Immich docs publish the exact dump-and-restore commands; test the restore once before you cancel Google One, not after. I kept my Google plan running for two months of overlap, restored one month's photos onto a scratch VM as a drill, and only then closed the account.
What I'd do
A used mini PC with 16GB RAM, SSD for Postgres and thumbnails, a big HDD for originals. Takeout at 50GB chunks, imported with immich-go, verified by spot-check. Smart search and faces enabled and left to churn overnight. Phones on the app the same week, originals kept on-device for a month, and a tested restore before the Google subscription dies. Total cost: about $200 of hardware you'll also use for other things, against $100/year forever — and photo search that happens on a machine you own.