Most people running two cloud services didn't decide to. One came with the phone, one came with the laptop, one came with a job, and now files exist in both with no rule about which is which.
That's the bad version. The good version is deliberate: two services, each with a defined job, a clear boundary, and no overlap. It's often better than consolidating, and it takes an afternoon to set up properly.
Why two is sometimes right
Separation of work and personal. The strongest reason. Work files in the employer's service, personal files in yours. When you leave the job, the split already exists and nothing needs untangling.
Platform strengths. One service integrates with your phone and photos; another handles files and collaboration better. Using each for what it's good at is reasonable.
Redundancy for the critical core. A second copy of your irreplaceable material with a different provider protects against account loss, suspension, or a provider-side problem. This is a genuine backup benefit that a single service can't provide.
Free tiers. Using a second service's free allocation for a specific, bounded purpose is legitimate — though it's the weakest reason and the most likely to produce mess.
Different sharing audiences. One service for clients who all use a particular platform, another for everything else.
The rule that prevents chaos
Every file has exactly one home. The other service either doesn't have it, or has a copy that's explicitly marked as a copy and is never edited.
That's the entire discipline. Everything else is implementation.
The failure mode you're avoiding is a file that exists in both services, gets edited in both, and diverges. There's no automatic reconciliation between providers, so divergence is permanent and you'll only discover it when the two copies say different things.
Four patterns that work
Pattern 1: Work and personal, hard split
Service A (work) Service B (personal)
Clients Finance
Projects Health
Admin Home
Marketing PhotosNo overlap at all. Different accounts, different folders, ideally different browser profiles so you don't cross-post by accident.
The one rule that makes it hold: nothing personal in the work service, ever. Not a scan of your passport, not your CV, not your tax return. Work accounts are controlled by the employer, can be revoked without notice, and their contents may be reviewed.
The mirror rule matters too: don't put employer files in your personal account. That's frequently a policy violation and occasionally a legal one.
Pattern 2: Primary plus critical backup
Service A (everything) Service B (the small critical pile)
All working files Tax records
All archives Contracts
Photos Identity documents
Documents Photos of people
Business essentialsService A is your daily driver. Service B holds only the irreplaceable core — usually a few gigabytes, often fitting in a free tier.
The copy into Service B is a one-way, periodic copy. You never edit there. Quarterly, you refresh it. That's the whole workflow.
This is the highest-value pattern for most individuals, because it addresses the risk that a single provider can't: your account being lost, hacked, or suspended.
Pattern 3: Split by file type
Service A Service B
Documents Photos and video
Spreadsheets Media libraries
Collaborative work Large archivesSensible when one service handles photos far better than the other, or when one has cheaper capacity for bulk material.
The boundary must be by type, not by importance or by recency, because type is the only boundary you'll reliably remember. "Photos and video are always in B" is a rule that survives; "the important stuff is in A" is not.
Pattern 4: Active and archive
Service A (active) Service B (archive)
This year's work Everything finished
Current projects Old client work
Live documents Completed productsUseful when B is significantly cheaper per terabyte. Archive-oriented and object storage services are dramatically cheaper for material you rarely touch, provided you can live without a polished interface and you check retrieval charges before committing large volumes.
The rule: things move from A to B on completion, one way, and never move back except as a copy.
Setting the boundary so you don't forget it
Write it down and put it where you'll see it. A file at the root of each service:
In Service A, _WHERE-THINGS-ARE.txt:
THIS SERVICE: work files only.
Clients, projects, admin, marketing.
PERSONAL LIVES IN [Service B]:
finance, health, home, photos.
Critical documents are copied to [Service B]/Critical quarterly.
Last copy: 2025-04-08The same file in Service B, pointing the other way. Ten seconds to write, and it's what future-you reads when the boundary has faded.
The specific mistakes to avoid
Syncing one service's folder into the other's folder. People sometimes point Service A's desktop client at a folder inside Service B's synced folder. Two sync engines then fight over the same files, producing conflicts, duplicates, and occasionally corruption. Never nest one synced folder inside another.
Automated two-way sync tools between providers. These exist and they mostly work, and when they fail they fail confusingly — duplicating files, propagating deletions in unexpected directions, and creating conflict copies in both services. One-way copies are fine. Two-way sync between providers is a source of problems.
Letting both services back up your photos. The most common accidental duplication. Both phone apps offer photo backup, both get enabled, and you're paying for two copies of the same library while consuming two lots of upload bandwidth. Pick one. Turn the other off explicitly.
No rule about where new files go. If you have to think about it each time, the boundary will erode within weeks. The rule should be answerable in one second.
Using the second service as general overflow. "Whatever doesn't fit in A goes to B" is not a boundary. It produces a random assortment in B that nobody can navigate.
Managing two on a computer
Both desktop clients can run simultaneously. Keep them separate:
~/ServiceA/
~/ServiceB/Both at the same level, neither inside the other. Use on-demand mode on both to keep the local footprint small.
Set your applications' default save location to whichever is your primary. The other should be somewhere you go deliberately.
On mobile, both apps installed, and — critically — decide once which one handles photo backup and disable it in the other.
Handling search across two services
The real cost of running two services is that searching means searching twice.
Mitigations:
Make the boundary predictable enough that you know where to look. This is the main one. A good boundary means you search once, in the right place.
Use your operating system's search, which indexes both synced folders locally as long as files are downloaded — though online-only placeholders may only match on filename, not contents.
Keep an index file if the split is complicated. A plain text list of what lives where, at the root of both.
When to consolidate instead
Two services isn't always right. Go back to one if:
- You can't state the boundary in one sentence
- You've found the same file in both more than once
- You're paying for capacity you don't use in either
- Everyone you share with is confused about where things are
- You're spending time managing the arrangement rather than benefiting from it
The exception is pattern 2 — the critical-pile backup — which is worth keeping even when you consolidate everything else, because it's protecting against a risk consolidation doesn't address.
The setup checklist
- Chose a pattern and can state the boundary in one sentence
- Wrote the boundary into a file at the root of both services
- Confirmed neither synced folder is nested inside the other
- Photo backup enabled in exactly one service
- No two-way sync tools between providers
- Set a quarterly reminder to refresh the critical-pile copy
- Default save location set to the primary service
Next in this series: Offline Access: Using Cloud Files With No Signal