How do I upgrade from Verint Community 13 or earlier?

Community 14 is fully containerized. Upgrading from Community 13 or earlier is effectively a migration into a fresh Community 14 runtime, followed by database and file-content transition.

Prerequisites

•  How do I install Verint Community? 
•  How do I install a production environment? 
•  How do I upgrade Verint Community? 
• Any custom plugins will need to be migrated Verint Community 14. This is a development task if an updated version does not already exist.

Prepare the Community 14 Stack

1. Create a fresh Community 14 stack using Compose.
2. Prefer bind mounts for:
   • SQL Server data
   • CFS content
   • Solr data
3. Start the stack once so the databases, folders, and initial configuration are created.

Initial Startup

Bring the Community 14 stack up:

docker compose up -d --remove-orphans

Wait for the initial install to complete, then stop the application tier while leaving SQL Server running:

docker compose stop web infra job

Restore the Community 13 Databases

Restore the old Community database into the newly-created Community 14 community_app database. If using a different database name, replace community_app.

Backup

-- Backup source DB (named 'CommunityDb13')
BACKUP DATABASE [CommunityDb13] TO DISK = '/path/to/backups/CommunityDb13.bak'

-- Backup source Reporting DB (named 'CommunityReportingDb13')
BACKUP DATABASE [CommunityReportingDb13] TO DISK = '/path/to/backups/CommunityReportingDb13.bak'

Now collect the backup files created. Place the files at /var/opt/mssql/backups/ in the SQL file mount and update their permissions to allow 'Everyone' read permission.

Restoration

Restore Community Database

Drop all connections to the community_app database.

DECLARE @DatabaseName nvarchar(50)
SET @DatabaseName = N'community_app'

DECLARE @SQL varchar(max)

SELECT @SQL = COALESCE(@SQL,'') + 'Kill ' + Convert(varchar, SPId) + ';'
FROM MASTER..SysProcesses
WHERE DBId = DB_ID(@DatabaseName) AND SPId <> @@SPId

EXEC(@SQL)

Drop the existing database.

DROP DATABASE [community_app]

List logical files in the backup set for use in MOVE actions during restoration.

RESTORE FILELISTONLY FROM DISK = '/var/opt/mssql/backups/CommunityDb13.bak'

Restore the backup files by moving them to the correct DB logical files.

RESTORE DATABASE [community_app] FROM DISK = '/var/opt/mssql/backups/CommunityDb13.bak'
WITH
    MOVE 'CommunityDb13' TO '/var/opt/mssql/data/community_app.mdf',
    MOVE 'CommunityDb13_log' TO '/var/opt/mssql/data/community_app_log.ldf'

Restore Reporting Database

Drop all connections to the community_reporting database.

DECLARE @DatabaseName nvarchar(50)
SET @DatabaseName = N'community_reporting'

DECLARE @SQL varchar(max)

SELECT @SQL = COALESCE(@SQL,'') + 'Kill ' + Convert(varchar, SPId) + ';'
FROM MASTER..SysProcesses
WHERE DBId = DB_ID(@DatabaseName) AND SPId <> @@SPId

EXEC(@SQL)

Drop the existing database.

DROP DATABASE [community_reporting]

List logical files in the backup set for use in MOVE actions during restoration.

RESTORE FILELISTONLY FROM DISK = '/var/opt/mssql/backups/CommunityReportingDb13.bak'

Restore the backup files by moving them to the correct DB logical files.

RESTORE DATABASE [community_reporting] FROM DISK = '/var/opt/mssql/backups/CommunityReportingDb13.bak'
WITH
    MOVE 'CommunityReportingDb13' TO '/var/opt/mssql/data/community_reporting.mdf',
    MOVE 'CommunityReportingDb13_log' TO '/var/opt/mssql/data/community_reporting_log.ldf'

Replace CFS Content

Replace the content of the Community 14 CFS bind mount with the CFS files from the Community 13 site.

If you are using a bind-mounted CFS folder, copy the files into that mounted location on the host.

After replacement, make sure the mounted folder remains writable by the Community containers. If needed, re-run...

docker compose up cfs-init

...which effectively runs this against the CFS. 1654 is the container's app user.

chown -R 1654:1654 /app/cfs

Run the Installer Upgrade

Run the installer and wait for it to finish:

docker compose up installer

Review the installer logs and confirm that database upgrade activity completed successfully.

If you need to force a fuller upgrade path, set DB_FORCE_UPGRADE=true and run the installer again.

Start the Remaining Services

Start the supporting services:

docker compose up -d infra

Start the application containers:

docker compose up -d job web

Review logs for:

• installer
• infra
• job
• web

FileInstallationPlugin may take additional time while file-based content is installed.

Validate the Upgraded Site

Validate:

• Community loads on http://LOCAL:8080, or your chosen host and port
• Expected content appears
• Search cores are reachable
• Background work starts normally
• No repeated upgrade or plugin-install errors appear in logs
• Health checks pass in Administration > Monitoring.

Notes on Site URL, Host Names, and Proxying

The sample stack exposes a single web directly on port 8080. To modify this, customize the port or non-default host name by modifying Core:SiteUrl and Core:ApplicationPort in settings.json and the forwarded port for the web service in compose.yml. Restart the stack after these changes.

Add a local hosts entry for the custom host name. This provides host-based access only. TLS and standard web ports still need an external reverse proxy or TLS offloader.

If using a reverse proxy, you can add more web instances by copying and pasting the web service into a web2, web3, etc, with different forwarded ports. Routing to these nodes would defined by the reverse proxy.