Migrate from Dropbox to Nextcloud

The Dropbox import runs per person. Each user authorizes the Dropbox integration app against their own Dropbox account, so an administrator cannot complete a migration for the whole organization from a single console. Plan the run as a list of accounts, each with a named owner who signs in, approves access and confirms the result. Expect each user's personal Dropbox files to land in that user's Nextcloud files area, which is where they will look first on cutover day. Before the wider run, confirm with the app's current documentation which content is carried across, how file versions and metadata are handled, and what happens to files that exceed the server's upload limits. Those answers determine what users must still do by hand after the import.

Folder paths are the most visible part of the result, so compare them with the Dropbox tree before users rely on them. Confirm whether the import keeps the original nested structure under the user's root, and how it handles file or folder names that Nextcloud rejects or that clash after conversion. Team and shared folders need a deliberate target chosen in advance. Decide folder by folder whether it becomes a personal folder for one user, a group folder shared with a Nextcloud group, or a Team Folder managed by administrators with its own quotas and permissions. Record each decision in a table with the source owner, the target, and the permission model. Team Folders must exist before the import, so an administrator should create them first, and the table should name who keeps access once the original owner leaves.

Sharing links are a separate task from the file import, so plan for them explicitly. Plan on recreating each active Dropbox sharing link in Nextcloud on the file or folder it now points to, and confirm with the app documentation what, if anything, is carried over, including expiry dates and passwords. Every recipient needs a mapping: an existing Nextcloud account, a new guest account for an external party, or a decision to retire the link. Keep this mapping in a register owned by the migration lead, with the link owner, original Dropbox path, Nextcloud target, recipient and permission level for each line. Recipients who open a link that no longer resolves will report the migration as failed, so the register should be finished before users are told the cutover date.

Test on a pilot group before the wider run. Choose users who represent the mix in your organization: a heavy file owner, a person who manages team folders, a person with many external shares, and a person with deep nested folders. Run their imports, then check a sample of files against Dropbox by name, size, modification date, folder location and whether each file opens. Confirm that re-created shares resolve for an internal recipient and for a guest recipient. Record every difference and decide in advance which ones are acceptable. Illustrative: if a pilot user's shared project folder lands as a personal folder, the team has learned to create the group folder before the import. Widen the run only after the business owner of each folder set signs off on the pilot results.

The first change users notice is how they sign in. Before the cutover, decide which identity path applies to each group: directory credentials through the LDAP app, which lets LDAP and Active Directory users appear in Nextcloud and log in with those credentials, or an OpenID Connect or SAML backend if your identity provider is already federated. Users who only know a Dropbox password will not be able to use it in Nextcloud, so the sign-in address, first-login steps and any two-factor enrollment must be written down and sent to each wave before it moves. Confirm with your identity team how sessions and password resets behave on the chosen path, because users will contact the help desk about these first.

Sharing links do not carry over. Every Dropbox link stops working at the cutover, and recipients receive nothing automatically, so each owner must recreate links in Nextcloud for the folders and files they share. Decide in advance which recipients are internal accounts, which are external people who receive a share by email, and which shares need a password or an expiry date. Use the per-user import report to list shared items, then give owners a short checklist and a deadline to resend. Expect recipients to ask why a link changed, and confirm with your administrators which sharing options are enforced by server policy in your release.

Desktop and mobile sync clients must be pointed at the new server and signed in again. A Dropbox client cannot sync to Nextcloud, so the old folder should be paused before the switch and removed only after the user confirms their files are in place. If an old folder stays linked to both services, users risk duplicate copies or conflicts. Confirm which desktop and mobile client versions are supported for the Nextcloud release you plan to run, and check that against the vendor documentation for that release before rollout. Publish the approved versions and the official download source to users so they do not install an unsupported build.

Some Dropbox features will not have a direct equivalent, and users will notice their absence on the first day. Build an inventory with the owners of each wave: which features they use, which integrations feed other tools, and which workflows depend on version history windows, file requests or similar Dropbox behavior. For each item, record whether Nextcloud provides it in the release you run, whether an app from the app store covers it, or whether the workflow itself changes. Mark every gap as an open decision with a named owner. Agreeing a replacement workflow before cutover is easier than explaining a missing feature to a team in the middle of a deadline. Confirm each entry against the documentation for your release.

Plan training and a support channel for every wave, not once for the whole project. Each wave should receive a short session on sign-in, sharing and the sync client, a written guide that matches the release you installed, and a named support channel with responders who understand the migration and can see the import report. Track the questions that arrive during the first days, because repeated tickets about the same link or client error usually point to a gap in the guide or the feature inventory. Schedule support coverage for the first full working days after each wave moves, and agree in the written scope with your provider which team answers which kinds of questions.