Introduction
This article explains how to completely remove NextGen from your on-premises deployment and return to the Legacy Teramind experience.
Rollback is destructive for NextGen. It removes NextGen services, files, Docker images, configuration, and NextGen database data. It does not remove Legacy Teramind data when NextGen was installed into its own database schema or into dedicated NextGen databases.
If you decide to enable NextGen again later, you must apply a TMU package that contains NextGen again. Running activate_nextgen alone will not work after rollback because the rollback removes the NextGen files that activation depends on.
Video
When to Use This Procedure
Use this procedure if you tried the NextGen on-premise experience and want to return fully to Legacy Teramind.
After rollback:
Your Legacy Teramind deployment remains installed and available.
The NextGen UI and service stack are removed from the host.
NextGen activation flags are cleared from the Legacy database.
NextGen database objects are removed from the configured NextGen schema or dedicated NextGen databases.
Important Database Safety Warning
Do not run rollback if Legacy and NextGen were installed in the same database schema. In that layout, Legacy and NextGen tables live together and cannot be safely separated by an automated cleanup. Running rollback in that situation is dangerous and can remove objects that should not be removed.
It is fine when Legacy and NextGen use two different schemas inside the same PostgreSQL database. For example, Legacy can remain in the default/public schema while NextGen uses a separate schema such as v2. It is also fine when NextGen was installed into dedicated external NextGen databases.
If your deployment uses the same PostgreSQL database and the same schema for both Legacy and NextGen, stop here and contact Teramind Support before continuing.
Before You Begin
1. SSH to the on-premise host.
2. Run the procedure only on the master node.
3. Make sure you have a current backup or VM snapshot.
4. Confirm the database layout before running rollback.
To review the NextGen-related configuration, run:
sudo grep -E '^msp_v2_|^msp_public_key=|^v2_nodes=' /usr/local/teramind/conf/teramind.config
Safe layouts usually look like one of the following:
msp_v2_database_schema=<schema>is set, for examplemsp_v2_database_schema=v2. In this layout, rollback drops only the separate NextGen schema.msp_v2_master_database_urlandmsp_v2_instance_database_urlpoint to databases dedicated to NextGen. In this layout, rollback cleans the dedicated NextGen database targets.
Unsafe layout:
NextGen was installed into the same schema as Legacy. Do not continue with automated rollback.
Run the Rollback
Run the rollback command:
sudo /usr/local/teramind/scripts/tm.pl -func rollback_nextgen
The script asks for confirmation before destructive cleanup starts. Type yes only after you have confirmed the database layout and have a backup.
For non-interactive maintenance windows, the confirmation can be skipped with -y:
sudo /usr/local/teramind/scripts/tm.pl -func rollback_nextgen -y
Use -y only when the pre-checks were already completed. The rollback cannot be undone without restoring backups or reinstalling/reactivating NextGen.
What the Rollback Does
The rollback performs these cleanup steps:
1. Stops the NextGen service stack and removes orphaned NextGen containers.
2. Removes NextGen database data:
in schema mode, drops the configured NextGen schema with
DROP SCHEMA ... CASCADE;in dedicated external database mode, drops NextGen-created public tables and standalone user-defined types from the dedicated NextGen database targets.
3. Clears NextGen activation flags from the Legacy database, including enable_msp, switch_to_v2_config, v2_manually_activated, and msp rows where type = 'v2'.
4. Removes firewall rules that were added for NextGen.
5. Deletes NextGen configuration keys from teramind.config.
6. Removes managed msp-* Docker image tags.
7. Deletes the NextGen directories under the Teramind installation.
8. Restarts the Legacy teraweb container.
Expected Success Message
When the rollback completes successfully, the command prints:
* rollback_nextgen completed (see /usr/local/teramind/logs/rollback_v2.log)
Verify Legacy After Rollback
1. Open the Legacy Teramind web dashboard.
2. Confirm users can sign in normally.
3. Confirm the NextGen switch/prompt is no longer displayed.
4. Confirm Legacy containers are running:
sudo docker ps --format 'table {{.Names}}\t{{.Status}}' | grep -E 'teraweb|terasrv'
5. Review the rollback log if anything looks wrong:
sudo tail -n 200 /usr/local/teramind/logs/rollback_v2.log
Troubleshooting
The command says it must be run on the master node.
Run the rollback on the Teramind master node. The script intentionally blocks rollback from non-master nodes.
Docker Compose cannot stop the NextGen stack.
The rollback stops before destructive cleanup if NextGen containers are still running. Check the Docker service and container state, stop the NextGen containers, and rerun the command.
The database cleanup fails.
The rollback stops before later cleanup steps if it cannot remove the configured NextGen database objects. Check database connectivity and privileges, resolve the database error, and rerun rollback.
The deployment used one schema for both Legacy and NextGen.
Do not use automated rollback. This layout needs manual handling because NextGen objects are mixed with Legacy objects in the same schema.