Connecting Dropbox to Google Drive: sync or migrate, not both

The first question is one most people skip: are you migrating or syncing? They are different projects with different endings, and the failure mode of not deciding is that you get an indefinite sync nobody owns, quietly accumulating conflict copies in a folder nobody opens.

Once that is settled, the difficulty is that Dropbox and Google Drive disagree about several things — what a valid filename is, what a folder is, what sharing means, and what happens when two people edit at once. Those disagreements are where the work is.

What we'll cover

• Migration and sync are different projects
• What does not map cleanly
• Sharing and permissions
• Building it with CodeWords
• Conflicts, if you are syncing
• Running a migration properly
• Links, which break everywhere
• Deciding what not to bring
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Migration and sync are different projects

A migration ends. It has a cutover, after which one system is authoritative and the other is read-only or gone.

A sync does not, and therefore needs an owner, monitoring and a conflict policy forever.

Bidirectional sync is the expensive option, and it is what people build by accident when they cannot decide.

One-way sync is much simpler and covers most real needs — a working folder mirrored for backup, or a shared output folder.

A partial migration is the worst case: two authoritative systems, both half-current, which is where "which version is the real one" becomes a daily question.

Decide and announce it. The technical work follows the decision, and without the decision the technical work has no end state to aim at.

What does not map cleanly

Filename rules differ. Characters valid in one may be rejected or altered in the other, and the alteration is silent.

Path length limits bite on deeply nested structures, which large Dropbox accounts accumulate.

Google Workspace files are not files. A Google Doc has no meaningful bytes to copy and must be exported to a format, which loses the collaborative version.

Dropbox Paper documents have the same problem in the other direction.

Version history does not transfer. The copy arrives as a single new version, and years of history stay behind.

Comments and annotations attached to files do not survive, which people discover after the cutover.

Shortcuts, aliases and symbolic links resolve differently or not at all.

Sharing and permissions

The part that causes real problems rather than inconvenience.

Sharing models differ. Folder inheritance, link sharing and per-file permissions behave differently enough that a mapping is a judgement.

External shares rarely transfer, so a partner who had access loses it silently at cutover.

Public links become dead links, including ones embedded in documents, emails and websites you do not control.

Default to restrictive and restore access deliberately, since the opposite error exposes files.

Audit before you start. Most organisations discover shares they did not know about, and a migration is the moment to close them rather than replicate them.

Tell people whose access will change, before it changes, which is the difference between a migration and an incident.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so both storage services and the reporting can sit in one automation.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which direction, which folders, how conflicts and unsupported files are handled.
3. Authorize the connections — Dropbox and Google Drive.
4. Describe the exceptions: a name that cannot be represented, a file too large, a Google-native document, a conflict.
5. Run it over one folder first and verify the result file by file before scaling.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Conflicts, if you are syncing

Two edits to one file is the normal case, not an edge case, on any shared folder.

Decide the policy explicitly: newest wins, source wins, or keep both.

Never silently overwrite. Losing somebody's work to a sync policy is the failure people remember for years.

Keeping both is safest and produces clutter, which is an acceptable trade if the clutter is named clearly and reviewed.

Deletions are the dangerous case. A deletion propagating across a sync is indistinguishable from an accident, and a delay before propagating deletions is worth having.

Report conflicts to a person, since a conflict file in a folder is not a notification and will sit there.

Running a migration properly

Inventory first: file count, total size, largest files, deepest paths, unsupported names, and Google-native documents.

Estimate from the inventory, since a large migration takes longer than any tool's estimate suggests.

Migrate in phases by team or folder, with a verified checkpoint after each.

Verify by count and checksum, not by eye, and keep the report.

Freeze the source for the cutover window, which is the only way to guarantee nothing is missed.

Keep the source read-only afterwards for a defined period, since somebody will need something that did not come across.

Links, which break everywhere

Links live outside the files. In emails, documents, chat messages, tickets and bookmarks, none of which the migration touches.

Sharing URLs are system-specific and will not redirect.

Links inside documents pointing at other migrated files are the ones that break most visibly.

Rewrite what you can — links inside documents you control — as part of the migration rather than afterwards.

Publish a mapping from old location to new, so people can resolve a broken link themselves.

Expect a long tail. Broken links will surface for months, which is an argument for keeping the source accessible rather than deleting it at cutover.

Deciding what not to bring

A migration is the only realistic opportunity to reduce what you are carrying, and skipping that step means paying to move a decade of material nobody will open.

Find the untouched. Files not accessed in several years are the bulk of most accounts, and they are the cheapest thing to leave behind or archive separately.

Find the duplicates, by checksum rather than by name, since the same file exists in five folders in every organisation of any age.

Identify the personal material that accumulated in shared storage, which is a conversation rather than a technical decision.

Check for what should not be there at all — credentials in text files, exported customer data, copies of things with retention obligations.

Archive rather than delete where you are unsure, to cheaper storage, with a documented location.

Get a decision per folder from its owner, in writing, since "move everything" is what happens when nobody is asked and it is the most expensive answer available.

Making it survive

Make transfers idempotent, verified by checksum, so a resumed run does not duplicate or corrupt.

Handle rate limits and quotas on both sides by pacing rather than failing.

Preserve timestamps where possible, since modification dates are how people find things.

Never delete from the source as part of a copy operation. Deletion is a separate, later, deliberate step.

Report the outcome: files transferred, skipped, renamed, failed, and the reason for each.

Limits worth knowing about

Storage quotas apply on the destination and a migration can exhaust one mid-run.

File size limits differ, and very large files may need a different route entirely.

API rate limits make large migrations slow regardless of bandwidth.

Shared drives behave differently from personal ones in Google Drive, including ownership and deletion semantics.

Compliance and retention obligations may constrain where files can live, which is a question to settle before moving anything.

What to build first

The inventory. File count, total size, the largest files, the deepest paths, names that will not survive, and every Google-native document. It moves nothing, it takes an afternoon, and it turns the migration from an open-ended job into one with a known size and a known list of exceptions.

Two habits make the difference. Decide explicitly whether this is a migration or a sync and announce it, since the indefinite half-migrated state is the expensive outcome and it is reached by default. And never delete from the source as part of copying — deletion is a separate decision, taken later, once somebody has confirmed the destination is complete.

Frequently asked questions

Should I sync or migrate?

Decide before building. A migration ends with a cutover and one authoritative system; a sync runs forever and needs an owner, monitoring and a conflict policy. The half-migrated state with two authoritative systems is the expensive outcome.

What does not transfer between Dropbox and Google Drive?

Version history, comments and annotations, shortcuts and aliases, and Google-native documents in any meaningful form — a Doc has no bytes to copy and must be exported, losing the collaborative version.

What happens to sharing permissions?

They rarely transfer cleanly. External shares are lost silently, public links become dead links including ones embedded in places you do not control, and the sharing models differ enough that mapping them is a judgement.

How should sync conflicts be handled?

Decide the policy explicitly — newest wins, source wins, or keep both — and never silently overwrite. Keeping both is safest and produces clutter, which is an acceptable trade if it is named clearly and reviewed.

What is the most dangerous sync case?

Deletions. A propagated deletion is indistinguishable from an accident, so delaying deletion propagation and reporting it to a person is worth the friction.

Why do links break after a migration?

Because links live outside the files — in emails, documents, chat and bookmarks — and sharing URLs are system-specific with no redirect. Rewrite the ones inside documents you control and publish an old-to-new mapping for the rest.

How do I verify a migration is complete?

By count and checksum, not by eye, with the report kept. Freeze the source for the cutover window and keep it read-only afterwards, because something will turn out not to have come across.

What should I do before starting?

An inventory: file count, size, largest files, deepest paths, unsupported names, and Google-native documents. It turns an open-ended job into one with a known size and a known exception list.

Should I move everything?

Rarely. Files untouched for years are the bulk of most accounts, duplicates by checksum are everywhere, and a migration is the only realistic moment to reduce what you carry. Archive what you are unsure about rather than deleting it.

What turns up during a file inventory?

Usually something that should not be there: credentials in text files, exported customer data, or copies of material with retention obligations. Worth looking for deliberately rather than migrating it into a new system.

Should I keep my Dropbox account after migrating?

For a defined period, read-only. Something will turn out not to have come across, and broken links will surface for months — both of which are cheap to resolve while the source still exists and impossible afterwards.

Does a one-way sync need less maintenance than bidirectional?

Considerably. It has no conflict resolution, no loops and no ambiguity about which side is authoritative, and it covers most real needs — a working folder mirrored for backup, or a shared output folder.

Related reading

• Automating PDF generation from data
• Dropbox and CodeWords
• Automating knowledge base updates