Hi bbaranowski ,
From what you've described, you've actually identified the root cause. The Invalid column name 'AccountExpirationDate' error is what we expect to see when a 2026.x server starts against a database that hasn't been migrated yet. The 2026.x server expects schema changes (like the AccountExpirationDate column) that don't exist in a 2025.3 database, and the group membership issue is another symptom of the same schema mismatch.
The missing step is the database migration. The server container doesn't perform schema upgrades automatically when it starts. Instead, the migration has to be run as a separate, one-time step before starting the new server. This is intentional so the upgrade is explicit and a database backup is taken first.
To answer your questions:
No , you don't need to upgrade through intermediate versions. You can upgrade directly from 2025.3 to 2026.2.11 . That's why trying 2026.1.22 produced the same error—the issue wasn't the version jump, it was that the database hadn't been migrated yet.
No , a direct version upgrade doesn't automatically migrate the database. The migration container needs to be run explicitly.
One important point: since you're upgrading an existing database, you'll want to use update mode (DVLS_UPDATE_MODE=true), not init mode. Init mode is only for creating a brand-new database. Update mode backs up your existing database, applies the schema changes, and then exits. DVLS_INIT and DVLS_UPDATE_MODE are mutually exclusive.
The upgrade process should look like this:
Restore your 2025.3 database snapshot so you're starting from a consistent state.
Pull the 2026.2.11 image.
Stop and remove the old server container.
Run the image once in update mode (DVLS_UPDATE_MODE=true), making sure you've configured a backup path/volume. The container will back up the database, apply the migration, and then exit.
Once the migration completes successfully, start the main server container normally.
The complete procedure, including the required environment variables and a Docker Compose example, is documented here under Version updates :
https://docs.devolutions.net/server/knowledge-base/how-to-articles/devolutions-server-docker-deployment/advanced-docker-configuration-for-devolutions-server/#version-updates
I also noticed that your docker-compose.yml contains a commented-out dvls_init section. Could you confirm how you're currently running the migration container? For an upgrade of an existing database, it should be running in update mode , not init mode.
