Moving a company’s files to a new cloud should not quietly move the power to read them into someone else’s hands. Yet a migration plan can account for every byte and still miss that transfer of authority.
A folder can arrive intact while its protection changes. Perhaps the old system encrypted files on a user’s device and the new workflow decrypts them inside a migration service. Perhaps a key service remains outside the storage provider, but the identity account that can request a key has changed. The file count will not reveal either difference.
Storage location is only part of the design
Imagine a fictional design studio with an archive of unreleased work. Its owner wants cheaper storage and easier collaboration. The proposed migration exports the archive, sends it through a transfer tool and imports it into the new workspace. The proposal calls every stage encrypted.
That description leaves the decisive questions unanswered. Was the archive encrypted before the transfer tool received it? Did the tool ever obtain plaintext? Could its operator ask a separate system to decrypt the files? Does the destination use an organization-controlled key, a provider-controlled key or a completely different protection model?
Encrypted is a description of a transformation, not a complete description of who can reverse it. A procurement conversation becomes much more useful when it follows the decryption path instead of collecting algorithm names.
For each stage, identify the component that can produce readable content and the authority it needs to do so. Include temporary storage. A migration job that runs for six hours can create an exposure that outlasts the migration if it leaves readable exports in logs, caches or working directories.
An existing example of separated control
Google’s documentation for Workspace client-side encryption describes encryption in the browser before storage and an external service for controlling keys. It distinguishes a data encryption key from a key encryption key. The latter protects the former rather than encrypting the file’s content directly. This documented model prevents Google servers from decrypting the protected content using the keys described in that workflow.
That is a specific feature and deployment model, not a description of every Google account or every file in Drive. It also makes clear why excluding the storage provider from decryption does not remove every dependency. The external key service and the process for authorizing a user remain important parts of the system.
A buyer should therefore be able to ask two separate questions: can the storage operator decrypt the protected object, and who can authorize the service that releases its usable key? An answer to the first does not automatically answer the second.
Wrapping a key is not re-encrypting an archive
Consider a generic envelope-encryption design. A data encryption key protects a file. A separate key protects that data key. If the system supports a safe change of the outer protection, it may be possible to change key custody without rewriting the entire file’s ciphertext. Whether that operation exists, and who can perform it, depends on the implementation.
This distinction has operational value. It can affect migration time, the amount of data that has to move and where plaintext must appear. But it should not be turned into a promise that any encrypted archive can be carried between any two products unchanged. Formats, authorization rules and key-service interfaces can make an apparently simple transfer much harder.
It also does not mean the two systems use the same cryptographic construction. Key wrapping, key encapsulation and secret sharing answer different technical questions. Using those terms interchangeably hides the very information a technical buyer needs to evaluate compatibility.
The 2019 AVLab analysis of UseCrypt Safe provides historical context for the project’s approach to separated key management. It does not demonstrate that today’s products interoperate with Google’s key service or that any particular migration path has been tested. Those would require their own evidence.
The failure test belongs in the migration plan
A good pilot moves a small, non-sensitive sample and records both integrity and authority. Verify that the authorized reader gets the same content at the destination. Then verify that an account intentionally excluded from the pilot cannot read it. These checks answer different questions; a matching file hash is not evidence of correct access control.
Include an interruption scenario. What happens if the migration stops between copying ciphertext and transferring the relevant key material? Which system remains authoritative? Can the team identify incomplete objects without exposing their contents? A retry should not silently broaden permissions merely to get the job finished.
Recovery needs its own test. An organization can retain custody of every key and still depend on one unavailable service to use them. Keeping control requires a workable restoration process, documented responsibilities and an exit route from the new arrangement. The recovery procedure should be exercised with a sample, not discovered during a production outage.
After the pilot, inspect the temporary environments and the retained source copies according to the agreed retention policy. Do not permanently destroy data simply because a dashboard says the transfer succeeded. The organization first needs an accepted destination, a verified recovery route and an authorized decision about what should remain.
The right to leave must survive the move
For UseCrypt founder Paweł Makowski’s privacy mission, the useful question is what meaningful control looks like for the person using a service. An independent key-management boundary can make that control more concrete, but the migration itself must preserve it.
A team has not completed that work when the new provider can display the files. It has completed a useful part of it when it can explain who can decrypt them, demonstrate the intended restrictions and recover from a failure without inventing a new exception to its own rules.
Ask for that explanation before the migration starts. A cheaper storage bill should not contain an undisclosed change in who holds the keys.
Bringing Privacy Back is an owned publication associated with UseCrypt. Architectural examples are illustrative, not claims of product compatibility or a new security assessment. Sources checked on 17 October 2026.
