The step that goes wrong is not the transfer

Moving a library between clouds is four steps: export, verify, upload, delete at source. Almost every guide to it covers the first, third and fourth. The failure that actually costs people photographs happens between them — deleting at the source before checking that what came out is what went in.

So the order below is deliberate, and the verification step is written at length because it is the one you cannot redo afterwards.

1. Export

Ask your current provider for a full export rather than downloading albums by hand. Two things are worth knowing before you start.

An export is usually not one file. Large libraries are split into several archives, and the split is by size rather than by album, so a single event can straddle two of them. Download all of them, and note how many there were supposed to be — the count is the first thing you will check.

Metadata often travels beside the photograph, not inside it. Many export formats write capture date, location and album membership into separate sidecar files rather than into the image. If you extract the archives and upload only the pictures, those photographs arrive with the date you uploaded them and nothing else. Every photograph in a fifteen-year archive dated to one afternoon is the classic outcome, and it is not recoverable from the uploaded copies.

2. Verify — before anything is deleted

Work through these in order. Each one catches a different failure, and the first three take minutes.

Count. Compare the number of files you extracted against the number the source service reports. A large gap usually means an archive failed to download; a small one usually means duplicates were de-duplicated somewhere.
Check the two ends of the timeline. Open your oldest photograph and your newest. Truncated exports fail at the ends far more often than in the middle.
Check the dates on a sample. Pick ten photographs from different years and confirm each one still carries its original capture date. If they all show today’s date, stop: the metadata is in the sidecar files and has not been applied.
Play a video through to the end. Video is where partial downloads hide, because a truncated file usually still opens and still shows a thumbnail.
Keep the export archives until the new copy is verified. They are the only intermediate you have, and they are cheap to keep for a month.

3. Upload

Upload the verified files into PhotoLog. Two mechanical facts are worth knowing while it runs.

Each photo or video is encrypted with its own key before it leaves your device, and the derived versions PhotoLog generates from it — a thumbnail, a preview — are encrypted under keys derived from that one. This happens per item, which is why a large first upload is bounded by your own device and connection rather than by a queue somewhere.

Uploading and organizing your library covers organizing what arrives.

Record your Recovery Code before you start, not after. PhotoLog asks for this at account creation for a specific reason: if you are the only member of a studio and you lose both your Recovery Code and every device you are signed in on, that studio’s content cannot be recovered — not by you and not by PhotoLog. A migration is exactly the moment when a whole archive is briefly held in one new place, so it is the worst possible moment to be casual about that. Keeping a second device signed in, or inviting someone you trust into the studio, gives you a second way back in.

4. Delete at the source

Only after the verification above, and after the uploaded copies have been spot-checked in PhotoLog. Then delete at the source, and check what the source service says about how long deleted content persists in its own backups — the answer is rarely “immediately”, and knowing the interval is part of knowing the migration is finished.

Why people move

The reason this route gets searched for is usually not a feature comparison. It is that a provider which can open your files can also analyse them, and a policy saying it does not is a different kind of assurance from an architecture in which the option is harder to take. No-AI storage sets out the difference and gives four questions to ask any provider, including this one, before moving an archive into it.

What this page does not claim

Not a claim about any specific provider’s export behaviour. The failure modes above are general to bulk exports. Your provider’s documentation is the authority on its own format.
Not a claim that no direct transfer option exists. This guide covers the export-and-upload path, which works regardless of whether a connector exists.
Not a claim that migration preserves everything. Album structure, comments, shared links and edit histories are frequently provider-specific and frequently do not survive an export in any form. Photographs and their capture metadata are what you can realistically expect to carry across.
Not a claim about what PhotoLog is unable to do. See how encryption works for the precise statement about where encryption happens and what its limits are.

How we verified this

Every statement above was checked against PhotoLog's own source and documentation on the date shown. Where the source did not settle a question, the page says so rather than filling the gap.

Each photo or video has its own key, generated once and never reused, wrapped under its vault's current key, and the original plus each derived representation is encrypted under its own key (verified 2026-09-01)
The three recovery paths for a lost account secret, and the fact that a sole studio member who loses their Recovery Code and every signed-in device cannot recover that studio's content (verified 2026-09-01)

Moving a photo library out of another cloud