Moving From Dropbox, Google Drive, OneDrive or iCloud? Do Not Confuse Cloud-to-Cloud Transfer With a Complete Migration

Short answer: yes, some cloud migrations can happen without first downloading every file to your computer. But a transfer that successfully moves the current file bytes is not automatically a complete migration of sharing permissions, version history, comments, cloud-native document behavior, ownership, timestamps, labels or application-specific metadata.

That distinction is the difference between a migration that merely looks complete and one you can actually trust.

pCloud, for example, currently documents a Third-party Backup feature that can import files from Google Drive, Dropbox, Dropbox Business and OneDrive directly into a pCloud account. That removes the need to manually stage the entire source library in a local folder first. But the pCloud help page describes a file-import/backup workflow; it does not promise that every source provider's revision graph, ACL model or application-native object semantics are recreated one-for-one.

Microsoft makes the broader problem explicit from the opposite direction. When files are copied between a work/school OneDrive and a personal OneDrive, Microsoft says the destination files are considered new items and can lose metadata such as Date created and Modified By; shared files also have to be shared again.

Apple gives another concrete example: if you copy a file from a shared iCloud Drive folder to another folder or another storage location, the file copy does not carry the original sharing access with it.

So the useful question is not:

“Did 82,431 files arrive?”

It is:

“Which parts of the source system did I intend to preserve, and which of those parts have actually survived the migration?”

First decide what “migrate” means for your library

People use the word migration for at least four different jobs.

If you only need a second recoverable copy of static files, a cloud-to-cloud import can be excellent.

If you are moving an active Google Workspace, SharePoint or Dropbox team environment, “all the files copied” can still be a failed migration.

That is why a serious migration starts with a preservation contract.

For example:

All binary files must arrive with matching relative paths and byte content. Google-native Docs will be exported to an agreed portable format. Existing sharing permissions will be rebuilt separately. Source revision history is not required. The source will remain read-only for seven days after cutover.

That sentence is testable.

“Move everything” is not.

For the broader reason a synchronized copy is not automatically an independent recovery system, see Cloud Backup vs Cloud Storage.

There are three main ways to move data between clouds

1. Server-side or provider-managed cloud-to-cloud import

The destination service authenticates to the source and copies supported data into the destination account.

Advantages:

• you do not need enough local disk space to stage the whole dataset;
• your laptop does not have to remain the permanent middleman;
• the workflow can be cleaner than nesting two desktop sync folders;
• the destination can report transfer status centrally.

Risks:

• only supported source services can be connected;
• source-native objects may need conversion;
• permissions and revisions may not map;
• API limits or provider-side restrictions still apply;
• the destination's definition of “completed” may describe file transfer, not preservation of every metadata layer.

2. Local download / sync, then upload to the new cloud

This is the universal fallback.

Advantages:

• you can inspect and hash source files locally;
• you can normalize filenames or convert unsupported objects;
• you can keep an independent offline staging copy;
• the workflow works even when the two providers have no direct integration.

Risks:

• requires sufficient temporary disk space;
• consumes local download and upload bandwidth;
• online-only placeholders can confuse what is actually local;
• two active sync engines can interfere if you try to make the same folder belong to both services;
• timestamps and permissions can change during the round trip.

If local storage is the bottleneck, do not assume that creating a nested Dropbox-inside-OneDrive or Drive-inside-pCloud sync tree is the answer. Use one transfer authority at a time.

3. Dedicated migration tooling or APIs

For business-scale migrations, administrators often use provider APIs or purpose-built migration tools.

This can preserve more structure than a crude download/upload, but it still has to translate between two different data models.

A Google Drive permission is not an NTFS ACL. A SharePoint version history is not a pCloud revision graph. A Google Sheet with protected ranges, macros and linked data is not equivalent to an .xlsx export merely because Excel can open it.

The tool may be excellent and the migration may still be intentionally lossy.

pCloud: direct third-party import is real — but understand exactly what it is

pCloud's current help documentation describes Third-party backups under Backups → Third-party.

Supported sources currently include:

• Google Drive;
• Dropbox;
• Dropbox Business;
• OneDrive;
• Google Photos;
• Facebook.

For Google Drive, Dropbox, Dropbox Business and OneDrive, pCloud describes one-time backups that are started manually. Its current dedicated help page says these can generally be run once every 28 days. Each backup is stored in a new dated folder.

This is useful for migration and redundancy because it creates a destination copy without requiring you to build a giant shared desktop sync tree.

There is another important behavior in the current documentation: files deleted from the source remain in pCloud after the backup. That gives the imported copy a different deletion relationship from a live two-way sync.

That is exactly why the feature is more useful as an import / backup boundary than as a claim that pCloud is continuously mirroring another cloud.

What pCloud's documentation does not prove

The help page does not promise one-for-one preservation of:

• Dropbox sharing roles;
• Google Drive permission objects;
• OneDrive Modified By history;
• source-provider comments;
• all source revision history;
• Google Docs/Sheets/Slides application semantics;
• arbitrary provider-specific labels or workflow metadata.

Do not silently assume those things migrate merely because the files appear in a dated pCloud folder.

If your source is primarily ordinary PDFs, photos, videos, ZIPs, project exports and other binary files, the gap may be small.

If the source is an active collaboration platform, the gap can be the whole project.

Google Drive: binary files and Google-native documents are not the same migration problem

Google Drive can contain ordinary binary files such as:

• JPEG;
• MP4;
• PDF;
• ZIP;
• PSD;
• RAW;
• Office documents.

It can also contain Google-native objects such as Docs, Sheets, Slides, Forms and Sites.

Those are not merely ordinary files with familiar extensions sitting on a disk.

Google's own documentation for migrating Drive content to supported third-party storage warns that unsupported content within a file cannot be migrated, and that deleting the original can make that unsupported content unrecoverable from the migrated copy.

Google currently documents integrations that let Workspace users migrate or work with certain Drive files through third-party providers such as Box, Dropbox and Egnyte. The same documentation lists unsupported features for those environments, including examples such as Forms, Sites, some mobile-app edits, linked content, macros, protected ranges, IMPORTRANGE, and Apps Script/API behavior.

The exact unsupported-feature list can change. The principle is stable:

A portable file export is not always a portable application state.

Dropbox's own help page reinforces the same point from the destination side. Dropbox says Google web-based files such as .gdoc, .gsheet and .gslides cannot simply be added or moved into Dropbox from somewhere else as ordinary web-based files. One supported approach is to export a copy to a portable format such as .docx and upload that exported copy — but then it is no longer the original web-based object.

Migration rule for Google-native content

Create an inventory before transfer:

1. ordinary binary files;
2. Docs;
3. Sheets;
4. Slides;
5. Forms;
6. Sites;
7. shortcuts;
8. shared-drive content;
9. files you do not own;
10. items with business-critical comments, protected ranges, scripts or linked data.

Do not use one migration rule for all ten classes.

If the reason you are leaving Google is storage pressure or a desire for a more storage-first architecture, Google Drive Alternatives is useful background. But a provider comparison should happen after you classify the Google-native dependencies that would be expensive to lose.

OneDrive: Microsoft explicitly shows why “copy” creates a new object

Microsoft's documentation for copying files from a work/school OneDrive to a personal OneDrive is unusually useful because it states the metadata consequence plainly.

Its current workflow says users can set up both accounts and copy files between them through File Explorer or Finder. Microsoft then warns:

• copied files are considered new in the destination;
• metadata such as Date created and Modified By is not retained in the same way;
• files that were shared need to be shared again.

That is an excellent general migration lesson.

Even when both endpoints are called OneDrive, crossing account boundaries can create new cloud objects with new collaboration state.

Moving to a completely different provider should therefore make you even more suspicious of metadata assumptions.

Microsoft gives another example inside its own ecosystem. When copying SharePoint/OneDrive documents with version history, its documentation says the normal Copy to operation copies only the latest version; earlier versions require separate handling.

So version history must be an explicit migration requirement. It does not come along automatically because the current .docx arrived.

If SharePoint or Teams is involved, this is no longer a personal storage migration

A Microsoft 365 document library can have:

• custom columns;
• SharePoint permissions;
• version history;
• retention policies;
• approval workflows;
• Teams relationships;
• OneNote notebooks;
• labels and managed metadata.

Treating that as “a folder in OneDrive” is how migrations silently lose business context.

For business data, inventory the collaboration layer separately from the file layer.

Dropbox: downloading a folder creates a separate local copy, not a magical migration bundle

Dropbox's current help documentation distinguishes downloading from syncing.

A downloaded file or folder is a separate local copy. Changes to that downloaded copy do not update the original Dropbox object.

That sounds obvious, but it matters during migration because a browser download is frequently mistaken for a complete export mechanism.

Dropbox also applies practical limits to folder downloads from dropbox.com. Its current documentation says a folder must be smaller than 250 GB uncompressed and contain fewer than 10,000 total files to download through that folder-download path.

That does not mean Dropbox itself only supports folders of that size. It means the browser download/export path has its own limits.

For a multi-terabyte Dropbox migration, repeatedly downloading giant ZIP files through the browser is therefore not automatically the best transfer architecture.

If the destination supports a documented Dropbox import — such as pCloud's current Third-party Backup — that may remove this browser-export bottleneck. You still have to audit what metadata the destination actually preserves.

iCloud Drive: Apple supports copying to another cloud location — but the copy is a new collaboration object

Apple's current archive/copy guidance is deliberately simple.

On iPhone or iPad, the Files app can copy items from iCloud Drive to another cloud service shown under Locations. On a Mac, users can copy iCloud Drive files into another local or mounted location. From iCloud.com, files can be downloaded to the device.

Apple also states an important limitation:

If you copy a file from a shared iCloud Drive folder to another folder, the original sharing access is not copied with it.

That is another example of the same migration law: bytes and collaboration metadata travel on different rails.

Apple also notes that if an iCloud Drive file is optimized/cloud-only, it has to be downloaded before the Files/Finder copy can proceed through a device-mediated path.

So for iCloud specifically, “copy to another cloud” may still involve local hydration even though the user interface makes the destination look like another provider location.

CloudScope will not call that server-side cloud-to-cloud migration unless the actual transfer path is documented as such.

A successful migration has at least six validation dimensions

A file-count comparison is only one of them.

1. Count

How many files and folders exist at source and destination?

Useful, but weak on its own.

A source with 100,000 items and destination with 100,000 items can still have missing bytes, duplicated paths, converted Docs, lost versions and broken sharing.

2. Relative path

Did the folder structure survive?

Watch for:

• illegal destination characters;
• path-length limits;
• case collisions;
• duplicate names;
• shortcuts converted into files or links;
• shared items landing in unexpected roots.

3. Byte integrity

For ordinary binary files, compare hashes where practical.

At minimum, sample large and irreplaceable files by independently downloading them from the destination and comparing against a trusted source copy.

4. Metadata fidelity

Check the fields you actually care about:

• modified time;
• created time;
• EXIF capture date;
• ownership;
• custom metadata;
• labels;
• filesystem attributes if relevant.

Do not compare every possible field merely because it exists. Define the contract first.

5. Collaboration state

Check:

• who can view;
• who can edit;
• owner/admin roles;
• public links;
• shared-folder membership;
• comments;
• file requests;
• expiration settings.

In many personal migrations this can be rebuilt manually. In a business migration it can be the hardest part.

6. Recoverability

Can you restore a representative file using only the destination system?

A migration is not complete if the only working copy remains hidden in the source account you are about to cancel.

The safest cutover is copy first, freeze writes second, delete source last

The riskiest cloud migrations are performed as a giant drag-and-drop while users continue editing both sides.

Use a controlled cutover instead.

Phase 1 — inventory

Record:

• total logical size;
• item count;
• large files;
• native cloud documents;
• shared folders;
• public links;
• files you do not own;
• version-history requirements;
• application-specific dependencies.

Phase 2 — pilot

Select a representative test set containing:

• small files;
• large files;
• deep folder paths;
• duplicate-looking names;
• photos with EXIF metadata;
• a native cloud document;
• a shared item;
• a file with meaningful version history.

Run the exact migration path you plan to use.

Phase 3 — bulk copy

Copy data without deleting the source.

A cloud-to-cloud import should be treated as copy first even if the business goal is eventually to move.

Phase 4 — verify

Validate counts, paths, sample hashes, metadata, sharing requirements and application behavior.

Do not accept “Completed” as the only evidence.

Phase 5 — freeze source writes

Choose a cutover point.

After that point, either:

• make the source read-only;
• stop editing it;
• or document a final delta-copy procedure.

If people keep changing both providers, you no longer have one migration. You have a synchronization problem.

Phase 6 — final delta

Copy changes made after the bulk transfer.

Verify again.

Phase 7 — destination becomes authoritative

Update shortcuts, applications, team instructions and backup jobs so they point to the new provider.

Phase 8 — retain source temporarily

Do not cancel the old provider the moment the transfer says complete.

The retention period depends on business and cost constraints, but the principle is simple: keep a rollback path long enough to discover migration defects.

Phase 9 — decommission deliberately

Only after the restore tests pass should you remove or downgrade the source account.

If your old cloud is your only remaining independent copy, deleting it can turn a migration mistake into permanent loss.

Do not run both providers as live sync owners during cutover

One of the most tempting migration shortcuts is:

1. sync Dropbox locally;
2. put that Dropbox folder inside OneDrive or pCloud Sync;
3. let both clients run;
4. hope the second cloud gradually becomes a copy of the first.

This creates two sync authorities watching overlapping filesystem state.

Renames, deletions, placeholders, conflicts and partial hydration can then propagate through both systems.

If you need redundancy, use an explicit one-way transfer, dated import, migration tool or separate staging copy.

Two clouds can improve redundancy. Two bidirectional engines controlling one local tree can reduce it.

When local staging is actually the better choice

A direct cloud-to-cloud import is not automatically superior.

Use a local verified staging copy when:

• the source contains important native documents that must be exported deliberately;
• you need an independent offline copy before closing the source account;
• metadata needs custom preservation;
• filenames need normalization;
• the destination has no trusted direct integration;
• you need to generate a checksum manifest;
• legal or compliance requirements demand an auditable migration artifact.

In that case, local disk usage is not wasted space. It is part of the migration control plane.

For long-term archive design, Cloud Storage vs External Hard Drive explains why cloud and local storage solve different failure modes rather than replacing each other one-for-one.

When pCloud's direct import is the cleaner option

pCloud is a particularly clean fit when all of these are true:

• your source is Google Drive, Dropbox, Dropbox Business or OneDrive;
• most important content is ordinary files rather than cloud-native workflow objects;
• you want a dated imported copy rather than another overlapping desktop sync root;
• you do not need the destination to recreate every source ACL/revision/comment exactly;
• you will verify the destination before cancelling the source.

It is a weaker fit when your real workload is heavily dependent on:

• Google Workspace collaborative semantics;
• SharePoint metadata and workflows;
• complex enterprise permissions;
• live cross-provider co-editing;
• source-native automation.

That is not a criticism of pCloud. It is an intent-to-architecture match.

A storage-first system should be judged on storage, retrieval, integrity and recovery. It should not be pretended into being Google Workspace or Microsoft 365.

The migration is finished only when you can answer these questions

Before deleting the old provider, you should be able to answer yes to the questions that matter for your contract:

• Are all required files present at the destination?
• Were unsupported/native objects identified and converted deliberately?
• Can high-value binaries be independently downloaded and verified?
• Are required timestamps and embedded metadata acceptable?
• Have required shares and permissions been rebuilt?
• Do destination applications open the migrated files correctly?
• Has the source been frozen long enough to catch missed deltas?
• Is there still an independent rollback copy?
• Can you restore a representative file without using the source account?

If the only evidence is a green Completed status and a similar-looking folder tree, the migration is not finished yet.

The copy may be done.

The verification is the part that closes the loop.