Dropbox

Dropbox into a SharePoint library

Copies a Dropbox account, a team folder, or a whole Dropbox team into SharePoint document libraries through the Migration API. The folder tree is rebuilt on the destination and each file keeps a modified date you choose, rather than every file arriving dated today.

What it does

• Whether each file arrived, with the Dropbox folder structure rebuilt underneath the library folder you picked.
• Which Dropbox date each file landed with: the one the uploading client supplied, or the one Dropbox itself recorded.
• Which Paper and cloud-native files had to be converted, and what they became. Every one is listed, because a converted file is not the original.
• Anything refused or still missing at the end of the run, per file.

How it runs

1. Sign in to Dropbox. A consent screen from Dropbox itself, asking for three read-only permissions. Nothing to register: ShareMaster is the registered app, so there is no client secret to hold and no developer console to visit.
2. Choose the scope. A personal home folder, a team folder, the team space, or a member's home folder. A team migration runs one scope at a time so each can land somewhere different.
3. Tick what you want. Everything under the scope, or cherry-pick folders and files.
4. Sign in to SharePoint and pick the destination. Site, library, and the folder under it. Folders that already exist are reused by their real id rather than duplicated.
5. Set the options. Dates, Paper conversion, and what happens to files already in the destination. Skip is the default and the only one that cannot lose a SharePoint edit.
6. It runs. Per-file progress with a live list, and a retry sweep at the end for anything Dropbox was still rate-limiting. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.

How it works

Dropbox is only ever read, through a connection that holds read-only permissions. The run first confirms what that connection can actually reach, then lists only the folders and files you ticked (or the whole scope). A selection that matches nothing stops the run as a fault rather than finishing as an empty success. Paper and other cloud-native files are converted to the format Dropbox offers, or left behind, as you chose, and each one is announced and listed.

From there each Dropbox entry follows the same path as an upload from this computer: the destination library must exist, folders already there are reused and missing ones created first, and under Skip the destination is checked so files already there are left alone. With Replace unless changed since, a file someone modified in SharePoint after the cutoff is kept; with Replace all, existing files are replaced, which on a versioned library keeps the old content as a version. Created is set to the Modified date you chose, because Dropbox records no creation date, and no author is set.

Files stream from Dropbox straight into the staging container, several at a time, while the previous batch imports. A file that fails to stage is retried; time spent offline does not count against its attempts, and anything still failing gets one more try after the last batch. After an import with errors, or one that stopped reporting, SharePoint is asked which files actually landed, and only the missing ones are failed. Files over the Migration API's per-file limit are uploaded directly to the library once the folders exist.

When a run finishes cleanly and copied something, Dropbox's change cursor for that scope is kept, so a later Incremental can ask Dropbox only for what changed. A run that left files out (on a trial licence about one file in ten is deliberately left out) keeps no cursor, so the next pass covers the same ground. Nothing in Dropbox is changed, moved or deleted. The run, with every conversion and every file left behind, is recorded in Migration history.

What you need

• A Dropbox account that can see the content. For a team migration that is a team admin sign-in, which is what exposes team folders and member home folders.
• Write access to the destination library, and the migration identity as a site collection administrator on the destination site. The app checks this before it creates the job rather than failing halfway.
• A Clone Master licence, or a trial.

What it will not do

• Version history does not come across. The current copy of each file is what lands, and Dropbox keeps its own revisions, so leave the Dropbox account readable until you are happy with the destination.
• Dropbox exposes no creator and no created time, so Created is set to match Modified and files arrive owned by the account that ran the import. There is nothing to preserve.
• Shared links, folder permissions and team access are not recreated. Content moves, access does not, and the destination library keeps the permissions it already has.
• Paper and other cloud-native files cannot be handed over as-is. They are converted and reported, or left behind and reported. Nothing is converted silently.
• A second pass carries changes, not deletions. A file deleted in Dropbox after the first pass stays in SharePoint.
• File sizes may change slightly after import because SharePoint can update embedded document metadata. A size difference alone does not mean the file is damaged. Compare and Differential match filenames and relative paths, not sizes; Differential copies only missing files. Use Incremental for source changes or the date-based replacement option to protect recent SharePoint edits.
• The compare report checks whether files are present. It does not verify their contents or prove that every size difference is metadata-only.
• One direction. There is no SharePoint back to Dropbox.

See every feature