Blueprint Developer Manual / Version 2506.0
Table Of ContentsFollow this section to migrate data from Elastic Core to SQL persistence for all editorial features that support this migration and previously used Elastic Core persistence. For details, please refer to the sections below describing the data migration for the separate features.
To migrate all data from Elastic Core to SQL persistence do the following:
Keep existing Elastic Core (MongoDB or In-Memory) configuration as before.
Enable SQL persistence as described above.
Set the following application properties:
-
Studio Server:
caplist.migration.enabled=true project.migration.enabled=true ### Enable the below line if you are running multiple ### studio-server instances on all but one studio-server ### (i.e., keep it at default `true` for one of the ### studio-servers that will now take care of the migration). # caplist.migration.on-startup=false ### Enable the below lines if you are migrating from In-Memory persistence: # userchanges.listener.enabled=false # workflow.server.archive.migration.enabled=true
-
User Changes:
caplist.migration.enabled=true -
Workflow Server:
workflow.server.archive.migration.enabled=true caplist.migration.enabled=true ### Enable the below line if you are migrating from In-Memory persistence: # repository.caplist.connect=true
-
Studio Server:
Restart the applications listed above.
If you migrate from In-Memory persistence, you must also start the User Changes Application now.
Check Migration Status / Result:
The applications will log start and completion of the different migration processes. Watch out for log entries containing these texts:
"Starting CapList data migration from Elastic Core" "Completed CapList data migration" "Starting migration of projects" "Starting migration of todos" "Finished migration of projects" "Finished migration of todos"
Example 4.30. Migration Log Messages for Studio Server
"Starting migration of Process archive" "Continue migration of Process archive" "Completed Process archive migration"
Example 4.31. Migration Log Messages for Workflow Server
Note
Migration of Projects/To-Dos:
There might be Projects or To-dos that cannot be migrated (completely) due to technical reasons, for example, because the name or the description is too long. To get a report on the issues call
GET actuator/projectmigrationon Studio Server or set propertyproject.migration.log-report=trueto write issues to the log file.Be aware that some migration processes will wait until a required migration of a different feature has been completed. For example, process archive will be migrated only after CapList migration has been completed.
Disable migration when completed.
When the migration is completed, you should disable it again by removing all properties that you have added before to your applications in step 3.
Clean-up properties and evaluate if you can remove MongoDB.
If you no longer use features that use Elastic Core persistence, the CMCC applications do not require a MongoDB connection anymore.
You might also want to clean up the application properties and remove any Elastic Core, MongoDB or In-Memory related properties.
