Whether you run Composer as a stand alone product or in an embedded environment, you can migrate supported versions to Logi Symphony following the steps outlined here. Generally, you’ll create your intended (target) environment, back up your current (source) environment, move your data, install Symphony with a customized YAML, bring over your users, groups, and tenants, and adjust other specifics to your software environment.
Important: If you are upgrading and have created an attribute named User.timeZone, this may be overwritten on upgrade. See Upgrade Workflow for more information about preparing your environment for the upgrade process.

​
Supported Versions

Logi ComposerLogi Symphony
23.4 and later24.2 and later

​
Migrate from Composer

Migrate your Composer stand alone or embedded environment by completing the tasks in this article. If you managed your users using the Composer / Visual Data Discovery API or support an embedded environment, there are further tasks to complete your migration. Review the steps below, then prepare your target and source environments for migration, installation, and customization.

​
Typical Scenarios

Upgrade diagram visualizing the steps to migrate from Composer to Symphony simple
Upgrade diagram visualizing the steps to migrate from Composer to Symphony for embedded environments

​
Baseline Migration Tasks

1. Kubernetes Cluster Before you begin, create your intended (target) environment to meet the following prerequisites, which are the baseline Symphony requirements. You will need:
  1. A Kubernetes cluster (versions 1.23-1.27) of appropriate compute availability.
  2. Install Kubernetes or have access to a cluster.
  3. Install the Helm CLI.
  4. Include a local copy of kubectl configured to work with your cluster.
  5. Helm (3.8-3.11). See Installing Helm.
  6. Access to the insightsoftware Docker Hub at https://hub.docker.com/u/insightsoftware.
  7. PostgreSQL 16 and above.
  8. RabbitMQ.
  9. NGINX Ingress Controller.
Prepare your environment, but do not install Symphony at this step. 2. PostgreSQL RDS Install a supported version of PostgreSQL for your new Symphony instance. 3. Backup PostgreSQL from Your Source Instance Back up your existing Composer databases (source databases).
Corresponding URLDatabase Name and URL
dbUrl"jdbc:postgresql://10.0.0.0:5432/zoomdata-qe"
metadataDbUrl"jdbc:postgresql://10.0.0.0:5432/zoomdata"
uploadDbUrl"jdbc:postgresql://10.0.0.0:5432/zoomdata-upload"
keysetDbUrl"jdbc:postgresql://10.0.0.0:5432/zoomdata-keyset"
userAuditingDbUrl"jdbc:postgresql://10.0.0.0:5432/zoomdata-user-auditing"
4. Create Databases and Restore PostgreSQL to Your Target Instance Create the databases you’ll need in Symphony for the modules you’ll deploy
  • Visual Data Discovery - create and restore your Composer data here.
  • Managed Dashboards and Reports - create corresponding databases to support content shared among all installed components.
  • Logi AI - create an AI database to support the use of Logi AI if deployed in your environment.
Visual Data Discovery Create the following PostgreSQL databases in your target Symphony instance: 
CREATE DATABASE "zoomdata-qe" OWNER "<defineuser>" 
CREATE DATABASE "zoomdata" OWNER "<defineuser>" 
CREATE DATABASE "zoomdata-upload" OWNER "<defineuser>" 
CREATE DATABASE "zoomdata-keyset" OWNER "<defineuser>" 
CREATE DATABASE "zoomdata-user-auditing" OWNER "<defineuser>"
Restore your backups from your Composer source to these target databases in Visual Data Discovery only. Managed Dashboards and Reports Create empty databases to support your Symphony environment. <defineuser> must match the owner you defined for the Data Discovery databases. Additionally, add the following extensions to the databases: uuid-ossp, unaccent. 
CREATE DATABASE "dundasbi" WITH OWNER "<defineuser>"; 
\connect "dundasbi"; 
CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "unaccent"; 
CREATE DATABASE "dundasbiwh" WITH OWNER "<defineuser>"; 
\connect "dundasbiwh"; 
CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "unaccent";
Logi AI If you’re deploying Logi AI in your environment, create an empty AI database to support it in your environment. <defineuser> must match the owner you defined for the Data Discovery and Managed Dashboards and Reports databases. Additionally, add the following extension to the database: uuid-ossp. 
CREATE DATABASE "LogiSymphonyAI" WITH OWNER "<defineuser>"; 
\connect "LogiSymphonyAI"; 
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
5. YAML Updates for Logi Symphony Deployment Start with the standard YAML provided as part of the Symphony deployment package for your target instance. You’ll need to make a few important changes to the global, managed, discovery, and logisections of the YAML. Include settings for ai if you are going to deploy Logi AI in your environment. 
global:
  # Disable the PostgreSQL from the helm chart.
  postgresql:
    enabled: false

managed:
  dundas:
    bi:
      appDb:
        # Setup the Dundas BI Databases
        appDbConnString: "Host=someservername;Username=test;Password=test;Database=dundasbi"
        warehouseDbConnString: "Host=someservername;Username=test;Password=test;Database=dundasbiwh"
        appStorage: "Postgres"
        
discovery:

  # The database username and password.
  defaultDbUsername: "test"
  defaultDbPassword: "test"
  
  
  # The database urls.
  queryEngine:
    dbUrl: "jdbc:postgresql://someservername/zoomdata-qe"  		
  zoomdataWeb:
    metadataDbUrl: "jdbc:postgresql://someservername/zoomdata"
    uploadDbUrl: "jdbc:postgresql://someservername/zoomdata-upload"
    keysetDbUrl: "jdbc:postgresql://someservername/zoomdata-keyset"
    userAuditingDbUrl: "jdbc:postgresql://someservername/zoomdata-user-auditing"		
    
    
logi:
  symphony:
    ai:
      # This is assuming AI (BETA) is enabled.
      database:
        host: "someservername"
        name: "LogiSymphonyAI"
        auth:
          username: "test"
          password: "test"
  1. Set postgresql to enabled:false (the default is enabled:true)
postgresql:
  # Enables a shared PostgreSQL server. This is defaulted to true,
  # however it is recommended in production to use an external database
  # See 
    enabled: false
  1. Change the database user name and password to match those you used during database creation (step 3) and restoration (step 4).
discovery:
  postgresql:
    # Do not change, when using Logi Symphony, the Postgres should come from the parent Logi Symphony chart.
    enabled: false
							
    # Do not change, when using Logi Symphony the ingress should come from the parent Logi Symphony chart.
    ingress:
      installController: false
      enabled: false
							
    defaultDbUsername: YourDatabaseUser
    defaultDBPassword: YourDatabasePassword
  1. Point your databases to the correct URL, IP, port, and database names.
query engine:
  dbUrl: "jdbc:postgresql://10.0.0.0:5432/zoomdata-qe"
  
    resources:
    limits: {}
    requests:
      cpu: 500m
      memory: 1.5Gi
		
zoomdataWeb:
  metadataDbUrl: "jdbc:postgresql://10.0.0.0.5432/zoomdata"
  uploadDbUrl: "jdbc:postgresql://10.0.0.0.5432/zoomdata-upload"
  keysetDbUrl: "jdbc:postgresql://10.0.0.0.5432/zoomdata-keyset"
  userAuditingDbUrl: "jdbc:postgresql://10.0.0.0.5432/zoomdata-user-auditing"
  resources:
  1. Save and deploy your revised YAML to your target environment.
6. Use the API to sync your imported users from Composer to the Symphony Instance At this point, you can log in to Symphony and see your content in the Visual Data Discovery module. No users, groups, or tenants are present in your overall environment. Use a POST API tool of your choice to sync the users to the full environment. Run the synchronization API
  1. Determine your Logon Session ID. Use this in your API tool to perform sync tasks.
  2. Define the licenseSeatKind in the body of your API POST. For example: 
{
    "licenseSeatKind": "4"
}
licenseSeatKindValue
Reserved Developer0
Reserved Power User1
Reserved Standard User2
Floating Developer3
Floating Power User4
Floating Standard User5
  1. POST to this endpoint: {{baseUrl}}/api/Admin/MigrateAccountServicesObjectsFromDataDiscovery?sessionId=<sessionId>
  2. Execute to synchronize all users across Symphony.

​
Migrate an Embedded Environment

If you run an embedded Composer environment, perform the tasks above to migrate your data, objects, and users.

​
Simple Embedding and Object-Level APIs

Once that is complete, make changes to your environment to enable your users to access objects.
  • Change the URL to include /discovery in the API paths. From/api/<endpoints> to /discovery/api/<endpoints>.
  • Update the Authentication TA API for your new URL.
  • Adjust the Embed Manager token URLs.
  • Update any custom APIs in use. See the Playground for examples.

​
Advanced User Management

If you are coming from a Composer only environment, you’ll need to create users, groups, and tenants using the Symphony user interface. If you used the Composer / Visual Data Discovery API endpoints, to create users, groups and tenants, you will now need to use these Symphony endpoints to manage these tasks:
Note: Note: Some references in the linked documentation refers to User accounts as Accounts.

​
Authentication Changes

If you are using Trusted Access, you should update your endpoints to include /discovery/ in appropriate paths. If you intend to manage users, groups, and tenants using API calls, set up authentication following the information provided here: Create and Use Logon and Session Tokens for Symphony.

​
Post Migration Steps

  1. Install the appropriate licenses for Symphony. See Add a License.
    Important: If you are upgrading to Symphony, Visual Data Discovery module from Composer, you will need add a license for Logi Symphony as well.
  2. Update any endpoints you use that have changed by replacing /composer/ with /discovery/ where appropriate. This impacts:
    1. bookmarks your users may use
    2. federated authentication redirect URLs
    3. proxy servers
    4. API endpoints you may use
  3. Inform users they’ll need to use the “Forgot my password” option when they log in for the first time to your new instance.
Important: If users don’t have an email address associated with their user account, run a script to return a list of users who are missing an email address.