Repair a cloud storage service when the need is still valid and the failure is narrow, replace it when the service repeatedly misses documented requirements, and retire it when the underlying need has ended. Make the decision from evidence about data recovery, sharing, security, cost, support, and portability, not from one frustrating sync incident.
Repair a narrow failure
Repair is appropriate when the provider still meets requirements and the problem has a known, reversible cause such as a paused client, expired credential, full quota, permission error, unsupported file, or temporary service incident. Preserve unsynced files, document the error, test one change, and verify a round trip between local and web copies.
Set a repair limit in advance: owner, deadline, acceptable workaround, and evidence required to close the issue. If the same failure returns after a confirmed fix, add it to the replacement case rather than restarting from memory.
Replace a service that no longer fits
Replace when required controls, capacity, collaboration, recovery, platform support, or cost cannot be met within an acceptable remedy. Include migration effort, retraining, integrations, retention, metadata, shared links, permissions, and exit fees in the comparison. NIST says an exit strategy should address normal and unexpected termination and that the ability to export all data in a usable, secure, reliable, efficient, and timely way is vital (NIST SP 800-144).
Run a pilot before committing. Export a representative set that includes large files, nested folders, shared items, version-sensitive documents, and names with unusual characters. Import it to the candidate service, open the files, compare counts and hashes where practical, rebuild sharing intentionally, and test access from required devices. A copied file without usable metadata or permissions may not satisfy the real requirement.
Retire only after proving custody
Retire when the workflow ended, data moved to an approved system, retention obligations are satisfied, and no active integration or user depends on the account. Export first. Google Takeout, for example, can create an archive for keeping records or moving data, but Google warns that recent changes may not be included between the request and archive creation (Google data export). Plan a final delta check instead of assuming one export is complete.
Verify the export by opening files, checking expected folders and counts, and performing a sample restore to the destination. Preserve audit, ownership, and retention evidence separately. Then remove integrations, app access, sync clients, shared links, service accounts, and billing only within the approved change window. Do not delete the old account merely because the new one appears to sync.
Record the decision
Use a short table with requirement, current evidence, repair option, replacement option, retirement condition, cost, risk, owner, and due date. Mark assumptions explicitly. The final decision should name the authoritative copy, backup location, restore-test result, access owner, migration or retirement date, rollback window, and unresolved exceptions. If export or restore cannot be proven, the service is not ready to retire; keep the decision at repair or replacement-in-progress.
Sources
- NIST SP 800-144 — National Institute of Standards and Technology
- How to download your Google data — Google