How to Migrate From ownCloud 10 Classic to ownCloud Infinite Scale

Illustrative scenario: Imagine a fictional 32-person design firm, Cedar Studio, that runs ownCloud Classic 10 with an LDAP directory, personal file areas, group shares, public links, and an external project-storage mount. The firm wants to move to ownCloud Infinite Scale (oCIS) without assuming that installing a new server will carry over its data or permissions. This example is hypothetical; it is not a report of a completed migration.

The supported path documented by ownCloud is a guided migration using the migrate-to-ocis app on the Classic server and occ commands. It is a staged transfer to a separate, clean oCIS target, not an in-place upgrade of the Classic database or data directory. The migration manual says the source remains operational through most of the process, but it does not describe continuous synchronization or a zero-downtime final delta pass. Plan a controlled cutover and confirm source-version compatibility and the final write-freeze procedure with ownCloud support before production use.

The steps below follow the official ownCloud Server 11.0 migration guide and Infinite Scale 8.2 auth and backup documentation available on October 6, 2026. Command syntax, environment variables, and support arrangements can change; confirm them against the documentation for your installed versions.

Step 1: Inventory the Classic instance and define what "migrated" means

For Cedar Studio, the first task is to list users, groups, enabled and disabled accounts, shared folders, link shares, external mounts, and any local users that do not exist in LDAP. Record which teams depend on each item. This avoids treating a successful transfer of personal files as proof that every old workflow has moved.

According to the migration guide, the migration can transfer enabled users and groups with memberships, each enabled user's home-directory files, and user, group, and link shares. Files are placed in each user's personal Space in oCIS. Disabled users and their files are skipped. The process does not migrate passwords or external mounts. Bytes residing in external mounts and received shares are excluded from the personal-file transfer and must be handled separately. Inventory those locations and assign a manual migration owner.

Also record whether passwordless public links are in use. By default, oCIS requires a password for public links; such Classic links can fail to migrate unless the target policy is changed. Do not weaken that policy just to preserve old URLs. Decide whether link owners should create new password-protected links instead. Passwords on migrated password-protected links will not match the old passwords, so users should reset them after cutover.

Step 2: Prepare a clean oCIS target and the migration connection

Build and test a separate oCIS instance before transferring production data. The migration guide requires both systems to be running and reachable from each other. It also warns that the target should be fresh and clean: preexisting users or data can conflict with imported content. Back up the current Classic instance and prepare a rollback plan that keeps it available until users accept the new service.

The migration requires an ownCloud-provided app installed on the Classic server. It is supplied as part of a guided migration; the documentation directs administrators to contact ownCloud support to obtain it. The app includes its own rclone binary. Do not substitute a random Marketplace package or an unrelated file-copy job for this app's documented process.

On the oCIS side, enable the auth-app service and the application authentication setting. The migration guide also requires impersonation to be active and an app token to be created for the oCIS administrator. The Infinite Scale 8.2 auth-app documentation explicitly says impersonation is intended for migration and should not remain enabled in a production deployment. Treat it as a temporary migration setting: protect the token, limit who can access it, and turn off migration-only impersonation after the work is complete. In a distributed deployment, apply settings to the correct service as the documentation specifies.

For the hypothetical Cedar Studio, the oCIS target should be tested with the same LDAP service the Classic server uses. Keep credentials in the deployment's secret mechanism rather than pasting bind passwords into shell history or a shared runbook. The official ownCloud migration guide lists the target requirements and points to ownCloud support for the migration app. The oCIS 8.2 auth-app guide explains app tokens and impersonation.

Step 3: Make identity mapping consistent, then run readiness checks

oCIS must be able to resolve the users and groups before their files and shares are migrated. Cedar Studio already uses LDAP, so its administrator would connect oCIS to the same directory, verify that users can log in, and check that identifiers map to the intended accounts. The ownCloud guide calls out unique, valid email addresses for every enabled Classic user. For LDAP-backed Classic users, it also calls out the username attribute, usually uid or samAccountName, and the corresponding oCIS LDAP schema settings. Match the attributes to the actual directory; do not copy sample values blindly.

If Classic uses local accounts but oCIS will use an external LDAP directory, create or migrate matching users and groups into that directory before file transfer. User and group names must match. The internal oCIS IDM is a limited embedded directory aimed at small setups or testing; ownCloud recommends a real LDAP or external identity-management system for production. The official migration procedure does not support a mixed population of local and LDAP-backed Classic users in one migration branch. Resolve that architecture with support rather than improvise halfway through.

Once the migration app has been installed and enabled on Classic, adapt the documented path and service account to your installation. The guide uses /var/www/owncloud and www-data as examples:

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

The verification command checks that enabled users have valid, non-duplicate email addresses. Fix reported issues before proceeding rather than skipping verification. If a disabled user needs to move, review the account, enable it on Classic before verification, and include it in the migration plan. Cedar Studio should also verify LDAP sign-in to oCIS with several representative users before the data transfer begins.

Step 4: Complete the user-and-group branch, then migrate files and shares

Follow the branch in the official guide that matches your identity setup. If Classic users are local and will use oCIS's embedded IDM, the guide's sequence includes migrating users, assigning an oCIS role, and migrating groups. One role is assigned to migrated users; Classic roles are not preserved one-for-one, and Classic subadmin privileges have no equivalent role in oCIS. Review admin access manually. If both systems use the same LDAP directory, make sure users and groups are already available to oCIS and follow the LDAP branch instead of creating duplicates.

After users, groups, and roles are ready, the documented file and share commands use the oCIS admin username as the final argument. The Classic admin password is requested interactively:

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

Run the file transfer before the share transfer, as described by the migration procedure. Users who have never logged in and have no files, or users missing from oCIS, are skipped by the file step. Shares involving missing users or groups can be reported as errors while the migration continues. For Cedar Studio, that means the team must inspect the command output and share inventory; completion without a fatal stop is not the same as proof that every share works.

The migration guide says successful stages cannot simply be repeated without removing the created target data first. A --force reset of initialization does not remove already migrated files from oCIS. Do not use reset flags as a routine retry strategy. If a stage fails, preserve logs, identify what was created, and consult the migration guide or support before deciding whether to repair the target or restart on a clean one.

Step 5: Cut over with a deliberate validation and recovery window

For a safe cutover, Cedar Studio would schedule a period when employees stop changing files in Classic, run the approved migration, then point clients and users to oCIS only after checks pass. This write freeze is an operational safeguard, not a claim that the migration app performs live synchronization. The published migration guide does not document continuous sync or a final delta-copy command. If the business cannot tolerate a write freeze, ask ownCloud support for a version-specific transition plan before promising a no-downtime move.

Validate with a checklist rather than a single administrator login:

• Confirm expected enabled users, groups, and group memberships appear in oCIS; confirm role assignments, especially for former administrators.
• Have users open representative migrated files from several personal Spaces, including large files and recently edited documents.
• Test internal user shares and group shares with both the owner and a recipient account.
• Open public links in a private browser session; reset passwords on migrated protected links and recreate links that failed policy checks.
• Recreate external mounts and separately migrate or reconnect the data they pointed to, then confirm that users have the intended access.
• Check desktop and mobile clients, sign-in, sync, and the support route for password resets before announcing the new address.

Keep Classic available in a controlled read-only or otherwise frozen state until the business owner signs off and required records have been checked. Remove the temporary impersonation capability and revoke the migration app token when no longer needed. Then take and test an oCIS backup using the procedure for its storage layout. The official oCIS 8.2 backup considerations say the instance must be fully shut down for the documented backup procedure and explain that metadata and file blobs may have separate storage paths.

What a successful migration looks like

In the Cedar Studio example, success is not merely that the oCIS web interface loads. It means employees can authenticate with the intended identity source, find their home-directory content, open team files, and use recreated or migrated shares with the expected permissions. Password resets, external mounts, and public-link changes are accounted for, while Classic remains available until acceptance. If any of those checks fail, pause the cutover, record the affected users and objects, and resolve the gap before treating oCIS as the system of record.