Nextcloud migration services

What a Nextcloud migration involves

A Nextcloud migration usually starts with one of four triggers: leaving a hosted suite such as SharePoint, Google Drive or Dropbox, meeting data residency rules that require files to sit in infrastructure the organization controls, consolidating an ownCloud or several older Nextcloud servers onto one instance, or absorbing a second organization after a merger. Each trigger changes the work. A residency-driven move may need to prove where every copy of a file lives, while a consolidation mostly needs to reconcile duplicate user accounts and overlapping group names before any data moves.

What moves and what is rebuilt. File content, version history, sharing links, group and user membership and quotas can be carried across with the right tooling, but each needs a mapping decision first. Sharing links and share permissions must be checked against the new group structure, and quotas should be reviewed because they often reflect old storage assumptions. Client sync state, app configuration, device sessions, two-factor enrollments and third-party app settings do not transfer cleanly. Plan for users to re-authenticate and re-sync, and confirm each app's configuration with the vendor or in a test instance before cutover.

In-house or partner. A team with Nextcloud administration experience can run a small, single-source move, such as one older server with a few hundred users and clean group data. Multi-source moves, permission mapping across inconsistent hierarchies and regulated data usually benefit from an outside partner for the mapping and cutover work, since errors there are expensive to find after users have started working in the new system. Ask any partner to show how it validates permissions after the move and how it will handle a rollback window.

What the work includes

A Nextcloud migration moves files, shares and users from a source system while keeping access rules intact. Each workstream below ends in a checkpoint that you can review before the next one starts.

Source inventory and data classification

We catalog every source library, site, team drive or share, with owners, sizes, file counts, activity and sensitivity labels. The inventory decides what migrates, what is archived and what stays behind, and it sets the scope the quote is built on. Confirm early who owns classification decisions.

Identity mapping

Each source account, group, guest and external user is matched to a Nextcloud identity, usually through LDAP, Active Directory or an OpenID Connect or SAML provider. Orphaned accounts, duplicate people and external collaborators without a sponsor are listed for a decision. Check how departed staff and shared mailboxes will be handled.

Permission and share translation

Source roles, inherited permissions, link shares and expiry dates are translated into Nextcloud groups, shares and folder permissions. Mappings that do not translate cleanly are written down with an agreed outcome, not silently widened. Review a sample of high-value folders with their owners before bulk transfer.

Bulk content transfer with delta passes

The first bulk copy moves most content while users keep working on the source. Delta passes then copy only changed and new items, and the final pass runs during a short freeze. Confirm the file size limits, path length rules and sync tool behavior of the source before scripts are written.

Validation and reconciliation

Item counts, checksums, sizes, timestamps and share counts are compared between source and target for each pass. Discrepancies are logged with a reason and a disposition, and the reports become part of the handover. Agree the acceptance thresholds with the data owners before the first trial run.

Client cutover and user communication

Desktop and mobile clients are repointed, old sync folders are retired and users are told when and how to switch. Cutover includes a rollback decision point and a support path for sync conflicts during the first days. Plan for users who work offline or on unmanaged devices.

Decommissioning the source

Once the agreed retention window closes, the source is set to read-only, archived or removed according to policy, and access is revoked. Evidence of final reconciliation and deletion is retained. Confirm legal hold requirements and any contract terms that apply to the source platform before this step.

What drives cost and duration

Each row names one factor that changes the effort of a Nextcloud migration, why it adds work, and a practical way to reduce it before the written scope is agreed.

Driver	Why it adds effort	How to keep it down
Users and accounts	Each user needs an identity mapped, group membership carried over, quotas set and a first login tested. Shared accounts and service accounts need a decision on who owns them in Nextcloud.	Remove disabled and departed accounts from the source before export. Confirm which identity source Nextcloud will authenticate against so accounts are not created twice.
Total data volume and file count	Transfer time, verification passes and storage sizing grow with bytes and object count. Very large folders with many small files often slow copy jobs more than raw size does.	Archive or exclude stale content before the move. Measure volume and file count per source area so the team can plan transfer windows and staging space.
Number of source systems	Each source (SharePoint, Google Drive, Dropbox, ownCloud or an older Nextcloud) has its own export format, API limits, permission model and sharing behavior, so each needs its own mapping and test.	Consolidate sources into a short list with a named owner per source. Retire sources with no active use rather than migrating them by default.
Depth of permission structure	Inherited permissions, broken inheritance, shared drives and external links must be recreated as Nextcloud groups, shares and folder rights. Each exception is a case someone has to decide on.	Clean permissions before the move: remove orphaned grants, flatten nested groups and list every external link that must survive. Agree which links expire during migration.
Version history retained	Keeping every historical version multiplies stored objects and extends copy and verification time. Version rules also affect storage quotas after cutover.	Set a retention limit for versions in scope, such as only current and recent revisions, and document what is excluded so users know what to expect.
Integrations that must keep working	Directory lookups, DLP scanning, email notifications, and apps that write to files each need a tested path. Any system that expects the old file location will break at cutover if it is not inventoried.	Build an inventory of every system that reads or writes the files, with its owner. Test each one against the staging instance before the cutover date is set.
Data classification and compliance constraints	Classified or regulated data may need encryption choices, residency controls, access logging and approval for each transfer step. These checks add review cycles and evidence to collect.	Classify data before the migration plan is written so restricted areas can be moved in separate waves with their own controls and sign-off.
Number of Nextcloud environments and client platforms	Production, staging and test instances each need the same configuration. Desktop, mobile and sync clients on different operating systems each need a cutover step and user communication.	Keep a single configuration baseline for all environments. Limit the number of supported client versions and publish a clear client update path.
Source-specific conversion	Google-native documents (Docs, Sheets, Slides) cannot be copied as-is and must be exported to office formats. SharePoint metadata, column types and library-level settings need mapping to Nextcloud tags or folder structure.	Decide which native formats are converted and which are archived as read-only exports. Map SharePoint columns to a short, agreed list of tags before any bulk transfer.

Migration phases and outputs

The sequence moves files, shares and users in controlled passes, and each phase closes with a written output the client can check before the next one starts.

Inventory sources and existing data
DeployOpen catalogs each source system, including file volumes, sharing links, groups, external shares and integrations that depend on the source. The inventory report lists what will move, what will not, and which owners must confirm scope. The step closes when the client signs off the report.
Design the target and map identities
The target Nextcloud layout is set out, covering folder structure, group and quota design, and how source accounts map to directory identities through LDAP, OpenID Connect or SAML. The mapping specification records each rule and the owner who approved it. It is complete when every source account has a defined target.
Translate permissions and record exceptions
Source permissions are converted into Nextcloud shares and group rights according to written translation rules. Cases that do not translate cleanly, such as nested inheritance or links with no owner, go onto an exceptions list with a decision for each. The step closes when the rules and exceptions list are approved.
Run a pilot with a small group
A limited group of users and a representative slice of data are migrated to a non-production instance. Results are compared against the source, and the pilot report records failures, timing observations and user feedback. Migration scripts are corrected before the full run, and the corrected scripts are kept under version control.
Execute the full migration with delta passes
The full data set is copied, followed by repeated delta passes that pick up changes made on the source since the previous pass. Each pass produces a migration log, and reconciliation compares file counts, sizes, checksums where feasible, and permission results against the inventory. The step is complete when reconciliation shows no unexplained differences.
Accept, cut over and roll out clients
Business owners test the migrated data and sign acceptance. A cutover runbook sets the final delta pass, source freeze, DNS or routing change, and rollback criteria, and client rollout notes guide users through sync client changes. Cutover is recorded in the runbook once the source is frozen and users are switched.
Support hypercare and decommission the source
After cutover, a hypercare period tracks support tickets, sync conflicts and permission complaints, with fixes logged. The source is then decommissioned according to the retention record agreed with the client, and a closure report documents final reconciliation, open items and handover. The schedule follows from the agreed scope and the number of sources.

What stays in-house and what goes to a partner

This table lists each part of a Nextcloud migration, the skills it needs, and whether teams usually keep it in-house or hand it to a partner, so you can decide where to draw the line.

Work part	Skills required	Usually in-house or outsourced
Business ownership and data classification decisions	Data governance, records management, legal and business owner sign-off on retention and access rules	In-house. Data owners must decide retention and access rules whichever path you choose; a partner can document options but cannot make those decisions.
Source access and admin accounts	Source platform administration (SharePoint, Google Workspace, Dropbox, ownCloud or older Nextcloud), account and token governance	Usually in-house. Accounts, API tokens and admin rights stay under your control, and a partner works through access you grant and revoke.
Identity mapping	Directory administration, matching users and groups across source and target, handling duplicates and leavers	Mixed. Your directory team usually owns the source of truth; a partner often drafts the mapping and tests it with your staff.
Permission translation	Nextcloud administration, understanding share models and group-based quotas, data governance review	Mixed. Translation rules need business sign-off; a partner can map and test permissions, but exceptions usually need in-house review.
Transfer tooling and scripting	Scripting against WebDAV or APIs, Nextcloud occ commands, error handling, rate limit and retry logic	Often outsourced. This is specialized work that is usually easier to build and reuse with a partner, with code kept in your repository.
Validation and reconciliation	File counts, checksums or metadata comparison, sampling methods, Nextcloud administration, source platform knowledge	Mixed. Acceptance criteria should be set in-house; a partner can run the reconciliation and report exceptions for your sign-off.
Client cutover support	Desktop and mobile client configuration, reverse proxy and DNS planning, freeze and delta sync procedures	Often outsourced for planning and runbooks, with in-house staff keeping the final go or no-go decision and user support on the day.
User training and communication	Change communication, short guides for end users, internal support triage	Usually in-house. Your staff know the teams and their workflows; a partner can supply material and sessions when scoped.
Decommissioning	Source platform administration, retention and legal hold checks, evidence of deletion or archive	Usually in-house. Retention obligations and legal holds must be confirmed by data owners before any source data is removed.

What usually goes wrong

Most Nextcloud migration problems are not technical failures of the server. They come from assumptions carried over from the source platform, from identity mismatches, and from cutover steps that were planned loosely.

Permissions copied without inheritance

Files often inherit access from parent folders in SharePoint, Google Drive or Dropbox. When only the flat list of users is copied, the inherited rules disappear and people either lose access or gain access to folders they should not see. Before import, document which access rules are inherited and which are set directly on each item, then rebuild group-based shares in Nextcloud and verify a sample of folders with users from each group.

Shares pointing to missing users

Share links and user-to-user shares reference accounts that must exist in the target before the share is recreated. If a collaborator was never provisioned in Nextcloud, the share either fails or is silently dropped. Build the user list from the source first, provision every referenced account, and confirm that each share target resolves to an active Nextcloud user or group before cutover.

Mismatched user identifiers

If a user is created with a different username or identifier than the one used by the directory or the source platform, their migrated content lands in a new account that nobody logs into. The files look present but belong to an orphaned account. Agree on one identifier per person, typically the directory account name or a stable email-derived value, and check that each migrated home folder maps to a live login.

Unsupported names and path limits

File names with characters that Nextcloud rejects, or paths that exceed the length the server or sync clients accept, can be skipped without a clear error in the migration log. Scan the source for invalid characters, trailing spaces, reserved names and long paths, rename or flag them in a mapping sheet, and reconcile file counts and total sizes between source and target after each pass.

Google-native and proprietary formats

Google Docs, Sheets and Slides, and some proprietary formats such as Microsoft OneNote notebooks, have no file-level equivalent in Nextcloud. Copying them as-is may produce stub files or nothing at all. Inventory these types early, decide whether to export to open formats, link to the source, or retire them, and state that decision to users before the migration window opens.

Sync clients still pointed at the source

Desktop and mobile clients keep the address of the old platform after cutover. Users who keep editing there create changes that never reach Nextcloud, and the divergence can be hard to see. Plan the client switch as a defined step: publish new connection instructions, redirect or disable the old source for writes, and check on a pilot group that clients have reconnected and are syncing to the new server.

Incomplete delta passes

A single bulk copy captures the state at one moment, while people keep working during the migration window. Changes made after that copy are missed unless a delta pass runs before cutover. Schedule at least one incremental pass that picks up modified and new items, freeze writes on the source for the final pass, and compare change counts for the window before declaring the migration complete.

Lost version history and metadata

Some tools copy only the current file content. Version history, original timestamps, comments and custom metadata can be lost, which matters for records retention and for audit questions about who changed what. Confirm which of these the migration method preserves, test them on sample files with known history, and record in the cutover plan what will not be carried over and who approved that.

How the work changes by starting point

SharePoint migrations start with the permission model, because it rarely maps one to one onto Nextcloud groups and shares. Plan the work around the structures that carry access rights.

Sites and libraries: Inventory which sites, libraries and folders hold live content, and which are archives that can stay where they are.
Permission inheritance: Document where access breaks from the parent, and decide which unique permissions become group membership and which become individual shares.
External sharing: List guest accounts and anonymous links, then confirm with the data owners which of them should continue after cutover.
Metadata: Confirm which columns, versions and retention labels must survive, and whether the export method keeps them.
Vendor and tenant owner: Confirm with your Microsoft 365 administrator which export tools and throttling limits apply to your tenant.

What you need to provide

The fastest way to shorten a Nextcloud migration is to name an accountable owner for each decision before work starts. A clear owner per decision usually saves more time than any single technical choice, because most delays come from questions nobody can answer, not from the copy itself. Start the input list with access. You need administrator access to each source system (SharePoint, Google Drive, Dropbox, ownCloud or an older Nextcloud server) with read rights to permissions and sharing data, not only to file contents. Ask the source owner to confirm in writing which accounts hold those rights.

Identity inputs come next. Provide an exported or queryable user and group list from your directory, and name the contact who owns directory and identity changes. If Nextcloud will authenticate against LDAP or Active Directory, that contact decides how accounts map to groups and what happens to users who leave. Confirm who can change group membership during the migration window, because group changes made mid-copy often break inherited shares. Also decide whether the target Nextcloud environment already exists or whether the platform decision (where it runs and how it is deployed) is still open.

Business decisions are the inputs teams most often leave blank. For each share and team, name a business owner who can approve which content moves, which content is archived and which permissions must not carry over, such as external guest links or broad domain-wide shares. Set retention and archiving rules in writing. Agree a change window for cutover and a communication owner who will tell users when to switch clients and where to find moved files. Each of these owners should sign off on their part, so that questions during the copy have a named person to answer them.

Common questions about Nextcloud migration

What drives the cost of a Nextcloud migration?

The main cost drivers are the number of users and data volume, the number of source systems (SharePoint, Google Drive, Dropbox, ownCloud or an older Nextcloud server), how much permission structure must be mapped, and whether identity integration and client cutover are in scope. Each source adds its own export, mapping and validation work. Ask for a quote that lists these items separately, with one-time migration work distinguished from any recurring support or Enterprise subscription. DeployOpen does not publish prices. A quote follows from the written scope.

How long does a Nextcloud migration take, and why is there no fixed figure?

Duration depends on data volume, the number of users and shares, how cleanly permissions map from the source, and how many test cycles and cutover windows the organization needs. No fixed figure is given without a scope because those inputs vary widely between organizations. The written scope should state the phases, the trial migration, the cutover approach and the acceptance checks, with a timeline attached to each deliverable. Ask for that breakdown before comparing proposals.

Can a small team migrate to Nextcloud on its own?

A small team can migrate on its own if it has someone comfortable with Linux server administration, database operations and the source platform's export tools, and if the data set is modest with simple sharing. Teams usually struggle with permission mapping, large or messy file trees, and the sequencing of a live cutover. Consider whether your staff can absorb that work alongside daily operations. A written scope lets you compare doing it internally against a partner's fixed-scope plan.

What does the migration need from our own staff?

Expect to provide access to the source systems, a named owner who can approve permission mappings, administrators for the target servers and identity directory, and staff to test representative folders and confirm results. Someone must also communicate the cutover date to users and decide which data is in scope. Ask the partner to list each dependency and its owner in the written scope so that delays are visible early.

Do file permissions, shares and version history survive the move?

Whether they survive depends on the source platform, the export method and how groups and users map into Nextcloud. Basic file structure and shares can usually be preserved, but native permission models, external links, and some version histories may not transfer exactly. Confirm this for each source during planning, and ask for a sample migration that shows which permissions and versions carry over and which must be recreated manually.

Do users have to change their sync clients after the migration?

Often yes. Moving to a new Nextcloud server or a new account usually means users must point their desktop and mobile clients at the new address and sign in again, and their local sync state may need to be reset. Plan the client cutover as its own step with user communication and a rollback approach. Confirm the exact steps for your source and client versions during planning.

Can we move directly from an older Nextcloud version to the current one?

No. Nextcloud does not allow skipping major releases during upgrades, so administrators must upgrade one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible. A migration from an older server therefore includes a stepwise upgrade path. Confirm the current supported major versions and their dates on Nextcloud's release schedule, and include the intermediate upgrades in the written scope.

What do we receive at the end of a migration engagement?

The deliverables should be defined in the written scope. Typically that includes the migrated data and users in the target Nextcloud, a migration report with exceptions, validated permissions and shares, a client cutover guide, backup and rollback notes, and documentation of the configuration. Ask for acceptance criteria and a list of items that must be handled manually after handover.

How DeployOpen runs Nextcloud migrations

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Nextcloud migration is scoped and delivered as written work in your cloud accounts, data centers or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the source systems (SharePoint, Google Drive, Dropbox, ownCloud or an older Nextcloud server) with file counts, sizes and sharing patterns
Map existing permissions, shares and groups to Nextcloud users, groups and share types, and record what cannot be carried over cleanly
Confirm the identity source, such as LDAP, Active Directory, OpenID Connect or SAML, before any user is provisioned
Agree in writing which client platforms, cutover window and user communications are in scope and which are not

How we build

Stand up the target Nextcloud version on the database and PHP versions its system requirements list for that release
Run migration rehearsals on a copy of the source data and compare file counts, checksums, shares and permissions against the source
Upgrade one major version at a time when migrating from an older Nextcloud server, with a backup taken before each step
Test third-party apps for compatibility and disable any that are not confirmed before the production migration begins

How we hand over

Deliver the migration runbook covering cutover steps, rollback points, maintenance mode use and post-migration checks
Document the permission mapping, exceptions and open items agreed with your data owners during scoping
Provide restore-tested backup procedures for the data directory or object storage, the database and configuration files
Train your administrators on the operating tasks they will own after handover, including client reconfiguration steps

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the migration closes
Plan the next major upgrade against the Nextcloud release and end-of-life schedule so the server stays on a supported major
Re-check app compatibility and client versions before each upgrade and record the results for your change records
Confirm with Nextcloud whether Community or Enterprise support fits your uptime and response requirements before go-live

Nextcloud migration