Why#
The hardest part of leaving a cloud service is not the technical migration. It is the audit.
Before you can move your data, you need to know where it is. All of it. Photos spread across multiple accounts, on phones that have changed over the years, in folders on drives that were last opened years ago. Some of it duplicated, some of it unique, some of it unidentified until you look at it directly.
The audit is also where you discover what you would lose if something went wrong.
That is the question that shapes everything that follows: how do you move nearly half a terabyte of irreplaceable family photographs without accepting any meaningful risk of loss? The answer is: you do not start the migration until a complete, independent copy exists somewhere outside every service you are about to leave.
Family#
The inventory covered four sources across three family members: years of photos and videos from Google accounts, from OneDrive, from old backups on an external drive that had been sitting in a drawer. When the numbers came together, the total was larger than expected — closer to eight hundred gigabytes of data on a single external drive, of which roughly half a terabyte was photos and videos that need a permanent home.
The Microsoft Family subscription got cancelled during this process. That was the right moment — the data was already safe, the decision was clean. Two accounts dropped to free storage tiers immediately. That adds a quiet deadline to the photo migration: new photos above the free tier limit will need a separate export before Part III, when the rest of the family joins the stack.
Nothing about any of this is visible to anyone else yet. The photos are still in Google Photos, still in OneDrive, still accessible the same way they have always been. The migration has not started. What this week produced is the precondition for migration: a verified, independent copy of everything, stored outside all commercial services, before a single original is touched.
Tech#
The approach for this kind of data is to secure first, migrate second. An external drive with all the data went to off-site storage — not as the migration target, but as the safety copy. Only after that copy was verified did the planning for the actual migration begin.
The transfer itself taught one useful lesson: any rsync of hundreds of gigabytes will eventually be interrupted. A laptop crash mid-transfer is not a disaster if you resume with the right flags — the tool can verify what arrived and continue from where it stopped without retransmitting what is already there. Running large transfers in a persistent terminal session, detached from the local shell, is the correct habit.
The migration planning surfaced a less obvious question: which machine should run the import? The answer was not the one that seemed most convenient. The laptop handling the external drive is near end of life — loading it with a multi-day import process is the wrong choice. The better answer was to move the drive physically to the server and run the import locally. No network bottleneck, no dependency on a machine that might not finish the job.
The import itself is not started. The tooling has been researched, the deduplication approach is defined, the metadata handling for photos that lack embedded dates is understood. The waiting condition is stability: the migration starts after the network layer and the operational foundations are settled, not before.
Project#
This workstream has a built-in patience requirement that the others do not.
The photo migration cannot be rushed. There is a verification period after import before any source is deleted — weeks of actual use, not a checkbox. The decision to delete Google Photos or clear OneDrive will be a deliberate act, not a side effect of the migration completing. That decision requires confidence that nothing was lost, that the duplicates were handled correctly, that the metadata is intact.
The irreversibility is the point. Getting this right matters more than getting it done quickly.