DVLS Upgrade Issue - Database Schema Error (from 2025.3 to 2026.2.11)
Hello,
I am writing to request your assistance regarding an issue we encountered while upgrading our Devolutions Server (hosted via Docker with an MS SQL database).
I recently attempted to upgrade our DVLS container directly from version 2025.3 to 2026.2.11. After starting the new container, we encountered the following database error:
Invalid column name 'AccountExpirationDate'
Additionally, as a result of this issue, all users were unexpectedly removed from their respective groups. It appears that there was a change in the database structure, but the schema migration did not execute properly.
Could you please advise on how to proceed?
To perform this upgrade correctly, is it necessary to upgrade step-by-step through all the intermediate versions, or should a direct upgrade handle the database migration automatically?
Thank you in advance for your support. I look forward to your guidance.
Recommended Answer
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.
Best regards,
Jérémie Perreault
All Comments (6)
Upon reviewing my docker-compose.yml file, I noticed that the dvls_init container section is currently commented out. I suspect that this container is responsible for executing the database schema migrations (which would explain the missing AccountExpirationDate column and the groups issue).
Could you please confirm if the following procedure is the correct and sufficient way to perform this upgrade?
Restore my VM snapshot back to version 2025.3 (to have a consistent database).
Uncomment the dvls_init section in my docker-compose.yml.
Set the image tag to 2026.2.11 for both the dvls_init and dvls_server containers.
Run the dvls_init container first to upgrade the database schema.
Once the initialization is complete, start the main dvls_server container.
Will running the dvls_init container automatically handle the entire database migration from 2025.3 directly to 2026.2.11 without the need to go through intermediate versions
I also tried a step-by-step upgrade by pulling version 2026.1.22 first, but the exact same 'AccountExpirationDate' database error occurs. What should i do?
I have a feeling the Docker container isn't upgrading the DB schema. I'm not a Docker expert, so I will need to check with someone here who is.
Can you please send me your schema (via direct message is best)?
The schema will help me determine if I'm on the correct path.
Stéfane Lavergne
Thank you for your reply. I have just sent you a direct message with the requested information.
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.
Best regards,
Jérémie Perreault
Thank you so much for your help! I managed to successfully update my instance. Previously, I simply changed the release tag to 2026.2, did a docker pull, and ran the container, assuming the migration would happen automatically in the background. It was totally my mistake for not scrolling down to the very bottom of the Docker documentation. Ironically, I somehow ended up reading the upgrade instructions for Windows instead! :D
Everything is up and running perfectly now. Thanks again for pointing me in the exact right direction!