Prerequisites before Migration
Docker installed with compose plugin (Docker Installation)
User is in docker group (Manage docker as non root user)
Running icom Router Management Binary Version on 2025.09.a
Downloaded icom Router Management Docker Version
insys-irm-2025_09_0b.tar.gzfrom icom Router Management Downloads
Migrate icom Router management binary installation to Docker
Preface
The icom Router Management (iRM) Server installation by application binary will not be
supported anymore. The installation and operation of iRM via docker compose will now be
preferred. This guide addresses all users that currently have a running binary installation, and
want to switch to the docker compose installation. All following steps and the migration as a
whole should be executed on the machine that currently hosts the iRM Server installation. This
ensures that all needed components are accessible and that all connected devices seamlessly
connect to the newly migrated instance running on docker.
Supported Version
icom Router Management Server (On-Premises) Version 2025.09.0a
Preparations
Before starting the migration process, a few prerequisites have to be met.
Verify that docker with compose plugin is installed
If you are not sure whether docker is installed correctly or not, enter the following command in the command line:
docker run hello-worldIf this command fails, please install docker with the compose plugin as described in the official installation guide. Also make sure that your user is part of the docker group.
Prepare the installation files
Download the installation archive for the iRM Version 2026.05.0 via the cloud platform and
upload it to your machine running the current installation of iRM.
Backup the database
In order to migrate all existing data to the new installation, a dump of said database is needed.
The following command will achieve this for a locally running database:
sudo -i -u postgres pg_dump -d insysicomroutermgmt -f /tmp/insysicomroutermgmt_backup.sqlThe database dump will be placed in the directory /tmp
Migration Process
First time docker installation startup
Start with shutting down the old systemd services:
sudo systemctl stop insysicom-routermgmt.service insysicom-autoupdate.service nginx.serviceChange into the directory you saved the new installation files in, and extract them into the newly
created directory for the docker installation:
sudo mkdir /opt/insys-irm
sudo tar -xzf insys-irm-2026_05_0.tar.gz -C /opt/insys-irm
sudo chown -R <USER>:<GROUP>/opt/insys-irmChange into the newly created installation directory and configure the host and db settings in
the .env file. It is important that the db_user defined here matches the database user of the old
database:
cd /opt/insys-irm sudo vim .envLet the system run its first-time startup:
./start.shWait for the complete startup to finish and stop the system again:
./stop.shMigrate existing data
Now that the new system ran once, all needed directories and components have been
initialized. Start with copying the local data from the iRM installation:
find /var/opt/insysicom-routermgmt/ -maxdepth 1 -mindepth 1 -type d -exec
sudo cp -r {} /opt/insys-irm/data/irm/ \;Prepare for applying the database dump on the new database:
sudo cp /tmp/insysicomroutermgmt_backup.sql /opt/insys-irm/data/postgres/Spin up only the Database:
set -a
source .env
source images/.irm-env
docker compose -f docker-compose-db.yaml up -dAnd apply the prepared database dump:
docker exec -ti insys-irm-postgres-1 /bin/bash
psql -U $POSTGRES_USER -d postgres -c 'drop database irm'
psql -U $POSTGRES_USER -d postgres -c 'create database irm'
psql -U $POSTGRES_USER -d $POSTGRES_DB < /data/postgres/insysicomroutermgmt_backup.sql
exit
docker compose -f docker-compose-db.yaml downIn order for the new system to work with the existing data, the masterkey of the old install needs
to be set in the config of the new system. Execute the following command to print the
masterkey to the cli:
echo "$(grep -oP '(?<=barracuda_master_key: ).*' /opt/insysicom- routermgmt/etc/insysicom-routermgmt.conf)"Copy the key and set the right value in the following files:
sudo vim ./config/insysicom-routermgmt.conf #replace value of barracuda_master_key
sudo vim ./config/insysicom-autoupdate.env #replace value of MASTER_KEYAfter these steps, the new installation should have inherited all local data like update packages, and all data saved in the database like router data, groups etc.
Configuring the application
TLS
Before starting the new system, it is advised to set the appropriate network mode and place all needed certificates in their respective spot. Set the preferred network mode in the .env file, depending in which mode the previous instance has been running:
sudo vim .envhttp
No further configuration needed.
https
If your system has previously been configured with https, you need to place your valid server certificate and its key into the certs directory and name them cert.crt and cert.key
sudo cp /etc/nginx/ssl/insysicom-routermgmt.crt /opt/insys-irm/certs/cert.crt
sudo cp /etc/nginx/ssl/insysicom-routermgmt.key /opt/insys-irm/certs/cert.keyhttps-mtls
If your system has previously been configured with added mtls for your devices, then
additionally to the certificates from https, copy your custom certificate authority c that has been
used for mtls to the certificate directory with the specified name:
sudo cp /etc/nginx/ssl/your_client_authentication-ca.crt /opt/insys-irm/certs/client-ca.crtCleanup and start of the new system
As the old installation using the systemd services is now obsolete, these services should be
disabled to not block the new applications from running on certain ports:
sudo systemctl disable insysicom-routermgmt.service insysicom-autoupdate.service nginx.serviceRemove any cronjobs connected to the old iRM installation from the following file:
sudo crontab -e # remove lines connected to insysicom-routermgmtFinally, start the new dockerized application:
./start.shYou should now be able to access your iRM installation from the same domain or IP as before and see all existing data. Devices that have been online before might need some time to start a reconnection attempt, depending on the time the system has not been reachable.