How to Migrate Your Cloud Storage to ownCloud Infinite Scale (oCIS) Without a Relational Database

For over a decade, deploying a private self-hosted cloud meant dealing with the standard LAMP stack (Linux, Apache/Nginx, MySQL/MariaDB, PHP). While platforms like ownCloud Classic (v10) and Nextcloud have served millions of users, their reliance on a monolithic PHP architecture and a central relational database is a notorious operational bottleneck. As your file library grows into millions of assets, database query performance degrades, schema migrations during upgrades become high-risk, and backups require complex, synchronized SQL dumps.

Enter ownCloud Infinite Scale (oCIS). Re-engineered from scratch in Go (Golang), oCIS completely discards the relational database. It operates as a cloud-native, microservices-based platform that stores metadata directly on the filesystem or S3 object storage.

If you are looking to upgrade your legacy ownCloud Classic setup to the lightning-fast, maintenance-free oCIS architecture, this guide covers the exact step-by-step migration process.

The Go Edge: Why Database-Free oCIS Changes Everything

Before initiating the transfer, it helps to understand why the architectural change is a massive upgrade for your self-hosted infrastructure:

• Platform Independence: oCIS compiles into a single, highly optimized binary. It does not require a web server interpreter (like PHP-FPM) or an external database daemon (like MariaDB) to run.

• Decoupled Microservices: The platform is broken down into autonomous services (gateway, frontend, storage, indexing). If one service crashes, the rest of the application remains online.

• The “Spaces” Concept: Unlike legacy setups where files are tied to individual user tables, oCIS introduces “Spaces”—dedicated collaborative data pools that exist independently of specific user accounts.

• Zero-Database Backups: Because metadata is persisted directly with your files on the storage layer, backing up your cloud is reduced to a simple filesystem snapshot or a standard S3 bucket replication.

Prerequisites: Preparing the Environment

To execute a clean, conflict-free migration, you will need shell/SSH access to both your source ownCloud Classic instance and a fresh, clean target oCIS server.

[ ownCloud Classic (Source) ]                    [ ownCloud Infinite Scale (Target) ]
- SSH Access Required                           - Fresh oCIS Instance
- migrate_to_ocis App Installed                  - auth-app service enabled
- All Users must have unique emails             - Clean, database-less filesystem

1. Verify User Emails: On your ownCloud Classic server, all enabled users must have a valid, unique email address assigned. The migration script uses emails as the primary identifier across systems.

2. Identity Strategy: oCIS strictly leverages OpenID Connect (OIDC) and LDAP for user authentication. If your Classic instance uses an external LDAP directory, configure the target oCIS instance to point to that same directory beforehand to keep user IDs synchronized.

3. Prepare the Target oCIS Environment: Your target oCIS instance should be entirely clean. You must enable the internal application authentication module. Add the following environment variables to your oCIS launch profile (such as your docker-compose.yml file):

environment:
  - OCIS_ADD_RUN_SERVICES=auth-app
  - PROXY_ENABLE_APP_AUTH=true
  - AUTH_APP_ENABLE_IMPERSONATION=true

Step-by-Step Migration Protocol

This migration relies on ownCloud’s official migrate_to_ocis integration app, which bundles rclone to safely sync files and recreate directory shares without modifying your active source server.

+-----------------------------------------------------------------------------+
|                          MIGRATION EXECUTION FLOW                           |
+-----------------------------------------------------------------------------+
|  1. Install & enable 'migrate_to_ocis' app on ownCloud Classic.             |
|  2. Initialize the connection to your new oCIS server IP/Domain.            |
|  3. Run validation scripts to flag duplicate emails or metadata errors.     |
|  4. Port user structures and recreate group directories.                    |
|  5. Deploy rclone stream to mirror files over WebDAV directly to oCIS.     |
+-----------------------------------------------------------------------------+

Step 1: Install the Migration App on ownCloud Classic

First, we must install the native helper utility on your source instance.

1. Download the migrate_to_ocis app package from the official ownCloud Marketplace.

2. Move the unzipped folder into your ownCloud Classic apps-external or apps directory.

3. Log into your source server via SSH, navigate to your root directory, and run the command-line utility (OCC) to enable the app:

sudo -u www-data php occ app:enable migrate_to_ocis

Step 2: Initialize Connection and Verify Data

Next, hook up your source instance to your new, database-less oCIS server.

1. Set up the migration pipeline by pointing the source OCC utility to your new target oCIS domain:

sudo -u www-data php occ migrate:to-ocis:init ocis.yourdomain.com

(If you are testing locally with self-signed SSL certificates, you can append the -k or --insecure flag to bypass certificate validation.)

2. Run the verification script to scan your source directory for duplicate emails, corrupt file links, or structural anomalies that could halt the migration:

sudo -u www-data php occ migrate:to-ocis:verify

Review the terminal output and resolve any flagged issues inside your ownCloud Classic dashboard before proceeding.

Step 3: Migrate Users and Groups

With the connection validated, we can now map our user base over to the fresh oCIS platform.

1. If you are using local (non-LDAP) users on ownCloud Classic, migrate the structural user accounts over to your target:

sudo -u www-data php occ migrate:to-ocis:migrate:users admin

(Use the oCIS admin token credentials when prompted. This step auto-provisions matches for all enabled users on the new server.)

2. Migrate your user-defined groups to ensure permission policies remain intact:

sudo -u www-data php occ migrate:to-ocis:migrate:groups admin

Step 4: Stream the File Data (The Transfer Stage)

Now we stream the physical files. Because oCIS doesn’t use a database, the files and their respective timestamps are migrated directly into personal user Spaces using the bundled rclone utility over WebDAV.

1. Start the file migration stream:

sudo -u www-data php occ migrate:to-ocis:migrate:files admin

This command runs sequentially, ensuring that file structures, file metadata, and timestamps are perfectly preserved during the network transfer.

Step 5: Migrate Share Metadata

With users and physical files safely residing on the database-free target, the final structural step is to port your shared folders.

1. Run the share migration command to recreate all public link shares and internal user/group sharing permissions:

sudo -u www-data php occ migrate:to-ocis:migrate:shares admin

(Note: Because authentication models differ between ownCloud Classic and oCIS, custom password protections on older link shares may need to be re-entered by users once the cutover is complete.)

Finalizing the Cutover

Once the migration scripts finish executing, verify the deployment:

1. Log into your new oCIS web interface (which runs on the sleek Vue.js-based ownCloud Web platform).

2. Inspect your Spaces directory to ensure the folder structures and modification dates match your source server.

3. Once validated, redirect your virtual hostnames (CNAME/A records) to point permanently to the IP address of your new oCIS server.

By shedding the relational database, you have effectively eliminated the heaviest maintenance liability of your self-hosted cloud. Your new ownCloud Infinite Scale deployment will run faster, consume fewer system resources, and scale effortlessly for years to come.