The purpose of the migration is to import the historical recordings from the Verint v15.2 solutions to the Verba system.
The migration offers the following features:
- IMR Financial Trading Recorder (IPC Media Recorder)
- BT Financial Trading Recorder
- Verint Financial Trading Recorder
Migration of historical recordings from Verint v15.2 systems
- Support for archived calls only
- Supported archive mediums: SMB folder or EMC Centera, Hitachi Content Platform (tapes, DVDs, or any other removable media is not supported)
- Storage targets are automatically created based on the archive configuration in Verint
- All Verint file formats and codecs are supported: wave file using G.729, G.723.1, or G.726
- Encrypted calls are not supported
- Both back office and front office (trader voice) calls can be imported
- Users, Groups, and Extension can be also migrated from v15.2 systems. The Users' conversation access scope is not migrated.
- Migrated calls are assigned to users defined in Verba based on their associated recorded extensions (Trader ID / Extension or Phone Number / SIP URI)
See Migration from Verint for more information on the migration process.
See Migration from Verint for more information on the limitations of the archive features.
Before you begin the migration, the following items must be completed and checked:
- The Verba system is deployed, configured, and tested.
- The Verba database is properly sized to accommodate the imported calls. Sizing estimate: ~5 KByte / imported call
- Sufficient time is planned for the migration. We recommend running the migration tool out of business hours to minimize the impact on the Verba database.
Front-office migration time estimate: ~5 million calls / hour
Back-office migration time estimate: ~3.5 million calls / hour
- All calls in Verint are archived, calls cannot be in the call buffer on the Verint recorders.
- The user configuration is complete in the Verba system for historical calls.
- The metadata mapping is checked and confirmed for both front-office and back-office calls.
The SQL Servers are linked:The Verint database has to be configured as a linked server on the Verba database server so the system can run queries on both systems during the migration. Server Options / RPC Out needs to be set to True in the Linked Server configuration. Once the migration is finished, the linked server configuration can be removed.
Alternatively, the Verint databases (Archive, BPMAINDB, CentralContact, and CommonDB) can be backed up and restored on the Verba database server.
For more information on configuring a linked server, see https://docs.microsoft.com/en-us/sql/relational-databases/linked-servers/create-linked-servers-sql-server-database-engine
- The recording functionality is turned off on the Verint recorders. This step is to ensure that no new calls are created on the Verint platform, so the system can migrate all historical calls. The migration supports partial migrations by defining date ranges. However, it has to be very carefully designed and tested to ensure all calls are migrated.
- All 3rd party database maintenance tools are disabled on both the Verint and the Verba database servers.
- The Verba Maintenance Job is disabled. For more information on disabling SQL Server jobs, see https://docs.microsoft.com/en-us/sql/ssms/agent/disable-or-enable-a-job.
- Verba database backup is created to be able to restore the system in the event of a fatal system error during the migration
- The necessary SQL scripts are executed on the Verba and the Verint databases (see below).
Running the SQL scripts
SQL scripts have to be executed on both the Verba and Verint databases before the migration can be started. The SQL scripts can be executed using the Microsoft SQL Server Management Studio which can be downloaded from https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms.
Running the SQL scripts on the Verba database
In order to run the SQL scripts on the Verba database, the SQL user requires the ALTER ANY LINKED SERVER permission or the sysadmin role to run these scripts. If you need help granting the permission, follow the article at https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-server-permissions-transact-sql.
The SQL script files can be found on the Verba Media Repository Server under the c:\Program Files\Verba\resources\db\verintmig folder. Execute them in alphabetical order on the Verba database before starting the migration:
6. update-programs-verintmig-fo-cti-15.sql (only from Verba 9.5)
8. update-programs-verintmig-fo-vox-15.sql (only from Verba 9.5)
9. update-programs-verintmig-us.sql (only from Verba 9.5)
Running the SQL scripts on the Verint database
Additionally, another SQL script must be executed on the Verint CentralContact database. If a DB backup was taken and the Verint databases were restored on the Verba SQL Server, then this script should be executed in the Verba SQL Server. So the programs this script will install are needed in the source Verint database.
This script is located at c:\Program Files\Verba\tomcat\webapps\verba\WEB-INF\verintmig\verintmig-download\verba-verint-centralcontact.sql, or can be downloaded from the Verba UI at the Verint Migration Source Database configuration page.
The script will add a new column to the Archive.dbo.Media table named verba_prio. Before starting the migration, this column has to be populated. Storage locations that are more likely to be available should be given a higher number.
The migration tool, available through the Verba user interface, provides the following features:
- Permission / Role-based access
- Multiple Verint database sources can be added
- For each database, multiple subsets have to be defined:
- Front-Office (based on time and selected Verint datasource)
- Back-Office (based on time and selected Verint datasource)
- Migration status information, configuration warnings (e.g. subsets configured does not cover all calls in the Verint database)
- Planning stage with data preview
- Data is migrated in monthly chunks
- The migration process can be paused and resumed later
- If the migration fails, it can be restarted from the last finished month
- Detailed logs
- The migration process is executed by the Web Application Service so the user can log off from Verba web UI and can turn their PC off
- No server restart is needed after the migration
- The performance of the Verba database can be degraded after the migration, if that happens, then the Verba Maintenance Job should be executed. This process might take several hours.
- The Verint databases are not changed, only four very simple helper procedures are installed (see Running the SQL scripts on the Verint database)
The Migration Tool migrates one call type (Back-Office calls or Front-Office calls) at a time. Once the first call type migration is complete, you are ready to migrate the remaining call type. The order in which you migrate the call data is not important.
Enabling the migration tool
The migration tool has to be enabled before the migration can take place.
Step 1 - Navigate to System / Servers or System / Configuration Profiles (in case you want to update the configuration profile used by the recording servers), then select the server which runs the Web Application service or the configuration profile.
Step 2 - Select the Change Configuration Settings tab and change the Web Application / Miscellaneous / Verint Migration Enabled setting to Yes.
Step 3 - Save the changes by clicking on the icon.
Step 4 - A notification banner will appear on the top. Click on the click here link, so you will be redirected to the Configuration Tasks tab. Click on the Execute button in order to execute the changes.
Step 5 - The Data / Verint Migration menu item will be visible when the logged-in user has Verint Migration permission.
The menu opens the list of the Verint Migration Source Databases. In most cases, there will be one Source Database, but the system allows migrating from multiple databases.
Click on the Add New Verint Migration Source Database link at the top right folder to add a new source database. First of all, the Verint version has to be specified: Verint v15.2 and Above.
When the Linked Server is empty, then the Verint databases (Archive, BPMAINDB, CentralContact, and CommonDB) have to be on the same server where the Verba database is. This can speed up the migration dramatically.
Details of a Source Database:
The setup, the log entries, the calculated numbers, and basically everything is stored in database tables and will not be deleted after completing the migration.
The Storage Targets will be synchronized during the migration of the first subset.
The source data is divided into Subsets. A Subset can be either Back Office or Front Office, and only one Subset may run at a time. The v15.2 User migration also creates a new Subset in order to simply track the process and the log.
The “Total” and “Source” numbers will be calculated either when the subset runs for the first time, or when you click on the Update Numbers button.
Front Office (Trader Voice) and Back Office (Telephony and Unified Communication)
First of all, a Datasource has to be selected.
You can optionally set From and To times to narrow down the migrated time interval.
The column mapping is pre-configured and cannot be changed on the UI. If it has to be changed, then the new XML mapping file can be uploaded in the Verint Migration Source Databases List screen, using the Upload New Column Mapping link at the top right corner.
A preview of the data (the first 100 records) is available on the Preview tab:
Running the migration
When the setup is complete and the Preview looks good, then use the Save and Run button to start the migration. The system will migrate one month at a time.
The Logs tab displays the progress and log messages:
The Select Run listbox contains one entry for one execution, so if the migration stopped or failed, and someone restarted, then a new entry will be inserted.
Use the SQLs checkbox to turn on detailed log entries with the actual SQL statements.
The execution can be paused by the Pause button. Pressing the button will not cause the termination immediately, but will change the status to Pausing. Once the migration of the current month finished, the status will go to Paused. The buttons are not refreshed automatically so if the Pause button is not visible while the migration is in progress, then go back to the list of the subsets and open the details again.
When the execution paused, finished, or failed, then the first tab will display the Run Again button that can be used to restart the migration of the Subset. Already migrated calls will not be migrated again, because they are saved in the verintmig_migrated_xxx tables.
One month is one transaction, and in case of an error in the middle, the whole transaction will be rolled back. In order to be able to effectively log to DB tables, we have to get out from the transaction, because otherwise, the log entries would not be visible to other DB sessions. In order to do this, a loopback Linked Server is created during the installation named verba_loopback.
If the execution fails, then the status of the Subset will be Failed, and the error message will be shown in the Logs tab. Unfortunately, there are errors that cannot be caught, and in that case, the subset will remain in the Running state. If you are sure that the process died, then click on the Mark as Failed button to set the state to Failed, then fix the problem and start the Subset again.
If a process is still running, then starting another one will throw an error: “Error during pr_verintmig_bo: Cannot acquire lock (Lock State: -1), probably another migration is still running (16, 1)”
Users, Extensions, and Groups
When migrating from Verint v15.2, the Users, Extensions, and Groups can be pulled from the Verint database. The process can be initiated by clicking on the Synchronize Users button on the Source Database details screen. The details (should Groups and Extension be pulled or not) can be configured on a new Subset configuration screen:
After the Subset saved, use the Save and Run button to start the migration.
The created Users will inherit the Language and Timezone settings from the User who is running the migration, and the Standard User Role will be granted to them.
The Verint identifier will be stored in the Verba database, so during call migration, the process will try to assign the calls to a User based on this information. If no migrated User found for a call, then the Extension and User setup will be used for user association.
The Verint Users' Extensions can be migrated too, will be set up as Number/Address type with Voice recording enabled.
The Verba groups are not sorted in a hierarchy tree, so the Group Name will contain the full path to the groups:
The User-Group membership information is also migrated, but the call visibility scope is not. No migrated user will be a Supervisor in Verba.
After the migration completed, the following items must be completed and checked:
- If the media files are stored on EMC Centera, then copy the PEA file to a location accessible by the Verba Media Repository Servers and change the configuration of the Verba Storage Targets to point to the new PEA file location
- If the media files are stored on the Hitachi Content Platform, then the Verba Storage Targets have to be configured with the correct API User and Password, because the Password was not copied from the Verint database
- Verify that calls are searchable and accessible through the Verba system.
- Verify that all Verint archive locations are available as storage targets in the Verba system.
- Verify that all calls are migrated by checking the information displayed on the subsets page.
Removing imported calls from Verba and resetting the import
If the migrated calls should be deleted and the Subset status should be "Planning", then use the manual-verintmig-delete-subset-calls.sql can be found on the Verba server in the Verba\resources\db\util folder. Set the ID of the Subset at the beginning of the file:
@subset_id INT = 0 -- TODO set subset id
Then execute the SQL in SQL Server Management Studio. The script will delete all calls of the Subset from the Verba database, and will reset the state of the Subset to "Planning".