Keep Takeout and Immich responsibilities separate
Use the original ZIPs as immutable evidence, repair into a portable output and import that output only after review. This makes it possible to diagnose a matching problem without also debugging an application database or storage-template migration.
Immich is under active development, so confirm the current import and backup guidance for the version you deploy.
Repair portable metadata first
Write dates, offsets, GPS and descriptions into formats that remain useful outside any one photo application. Keep a CSV report mapping each Takeout path to the repaired output.
Immich currently documents date, description, location and tag fields that it can read from XMP sidecars, but Google supplemental JSON is not the same format as an XMP sidecar. Reconcile Google JSON before assuming the destination will understand it.
Choose upload or external-library behavior deliberately
An Immich upload copies media into its managed library, while an external library indexes mounted files. Read-only external libraries protect originals from application writes but also limit metadata edits that require XMP write-back.
Decide whether the repaired output is a managed import or a separately backed-up external archive before starting a large job.
Keep dynamic-photo resources together
Preserve HEIC or JPEG stills and their short MOV resources in the same organized directory. Do not manufacture Apple identifiers when both sides have lost the original value.
Review how the current Immich release handles the pair before deleting any separate video resource.
Import only after verification
Review failed and unmatched items, compare file counts and retain the original ZIPs. Import the repaired output rather than deleting the only source after the first successful-looking timeline.
Back up both media and the Immich database according to the project documentation; a database backup alone is not a backup of the image and video files.