Currently, we are using Bahmni (version 0.93) in a medical center. We have reviewed the new Bahmni-lite v.1.0.0 (with docker) and are very impressed with it. However, we haven’t come across any documentation on how to perform the migration of configurations and data. Is it possible to carry out this migration? If so, how is it done?
Thank you.
Hi Pablo,
Glad to hear you liked the Bahmni LITE release! 
The Bahmni LITE is not a full replacement for Legacy Bahmni v0.93, since LITE doesn’t contain OpenELIS/Odoo/DCM4chee. That will come as part of Bahmni Standard Release, which hasn’t yet happened. A development version of Bahmni-standard is packaged in the docker (bahmni-standard subfolder), which people can try.
But if all you need is the EMR component of V0.93 to be migrated over to Bahmni Lite (no Odoo, no ELIS, no DCM4chee), then you should just be able to point the new Bahmni LITE to a clone of the older DB, and on process of coming up, Bahmni LITE will run liquibase changes on the DB. We have done this at one facility which upgraded just the EMR portion to use LITE binaries, while leaving OpenELIS/Odoo untouched.
There isn’t any documentation on migration because we will test that aspect when we perform a Bahmni Standard (docker) release. The LITE release is currently targetted towards new adopters, who don’t have significant migrations to be done.
Please try out, and provide us feedback. Will be helpful to know. Thanks!
Also, to point your existing bahmni-config to be picked by docker, you will need to follow these steps: Using Implementation specific Configuration (docker) - Bahmni Wiki - Confluence
So, DB needs to be your v93 one. Config needs to be your v93 one. Try this out first with a TEST setup and see how things look.
few other things - clinical forms (Forms2) and uploaded files directory - those need to be backed up and put on a mounted volume. @mohant any inputs here?
The docker backup/restore script can give you guidance on right locations within docker (for Databases and documents sub-folder):
Like Pablo, we have Bahmni running on a CentOS server and trying out the docker version. I am getting back into this after several years and amazed at the progress and commitment of the team, congratulations! I am testing the docker lite version on Windows, comes up neatly with the demo database. However when I bashed into openmrsdb container, replaced the database with a dump of our clinic’s database I am getting liquibase issue - during openmrs initializer. “Caused by: liquibase.exception.LiquibaseException: liquibase.exception.LiquibaseException: Unable to execute change set: liquibase.xml::bahmni-emrapi-202208101439::BAHMNI” “Caused by: liquibase.exception.DatabaseException: Expected single row from select count(rmap.concept_id) from concept_reference_map rmap bahmni-lite-openmrs-1 | INNER JOIN concept_name cn on cn.concept_id = rmap.concept_id and cn.name=‘Visit Diagnoses’ bahmni-lite-openmrs-1 | and cn.concept_name_type=‘FULLY_SPECIFIED’ and cn.voided=0 and cn.locale = ‘en’ group by rmap.concept_id having count(*) = 1 but got 0”
I think I am missing a step - saw reference to openmrs_config - which I don’t find in lite version. Any thoughts? Thanks,
This changeset actually creates a concept called “Visit Diagnoses”, which is now also present in the CIEL dataset that standard is bundled with.
If you have restored your database and configurations (app-configs) - then you should not have problem. But maybe there are other possibilities as well.
to check
select distinct concept_id from concept_name where name = “Visit Diagnoses”;
If you find more than 1, then on the database, you can rename the CIEL concept’s FSN name like
select * from concept where uuid = ‘159947AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’;
With the concept_id returned above - identify the conflicting concept names.
select concept_name_id, name, locale, locale_preferred, concept_name_type from concept_name where concept_id = ?;
There should not any name with locale_preferred=true and concept_name_type = ‘FULLY_SPECIFIED’ for locale=‘en’.
So, update the concept_name accordingly
update concept_name set locale_preferred=false, name=‘Visit Dx’ where locale=‘en’ and concept_name_type=‘FULLY_SPECIFIED’ where concept_name=?
Thanks, Angshuman, I think you hit the nail on the head - the above is what I am struggling with. I have moved to using bahmni-standard, my interest is only openmrs for now. Should I create a custom bahmni-config docker image based on my Centos config along with restoring the database. Where should my existing bahmni-config files be moved to get built with the image. I expect " Liquibase Migrations for OpenMRS:" will then happen smoothly on startup (and be consistent with the data in the database).
any particular reason that you don’t want to use your older app config? standard-config will have things referencing the metadata. You can use the standard config but you definitely have to relook at the configuration, especially some of the metadata setup.
You can always fork bahmni-docker and modify the services in docker compose file. But in simple words, you need to just restore your database and configure the app-configs. You can always modify the profile definition in the docker compose file, or create a new one.
We will be doing sessions on upgrade next week. Please check posts on the release announcement thread.
So after the learning from the upgrade sessions, I started using the standard config master, set the config_volume to this standard config in my host, commented out the config service and did the restore with the backed up database. I am now getting this message on https://localhost/openmrs/initialsetup - Caused by: liquibase.exception.DatabaseException: Table ‘emrapi_conditions’ already exists [Failed SQL: (1050) ALTER TABLE openmrs.conditions RENAME openmrs.emrapi_conditions] at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:393) at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:82) at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:150) at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1279) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1261) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:660)
I am not seeing emrapi_conditions anywhere in the standard config master. Guess it is part of the openmrs initializer image?
Since the tables were empty, I kept dropping them from the schema just see if the initialization step went through. The tables I dropped: emrapi_conditions, order_set_attribute, order_set_attribute_type, order_group_attribute, order_group_attribute_type. Now I am getting this error.
The following error occurred at startup: Unable to start OpenMRS. Error thrown was: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘providerRolesLineProcessor’: Lookup method resolution failed; nested exception is java.lang.IllegalStateException: Failed to introspect Class [org.openmrs.module.initializer.api.providerroles.ProviderRolesLineProcessor] from ClassLoader [{ModuleClassLoader: uid=1196747088; initializer}]
@ashokraman Have you been using any custom OMODs in your older version ? Also, instead of starting with standard-config, can you try mounting your existing config from your old server and start the migration once.
@mohant thanks for the quick response. No, no custom OMODs used. The existing bahmni-config from old server does not have the masterdata folder - it just has offline, openmrs and openelis (which is not being used). I will try pointing to it in the config volume and see how it works.
I updated docker, maybe I shouldn’t have. Here are my system configurations:
docker -v
Docker version 27.1.1, build 6312585
ver
Microsoft Windows [Version 10.0.22631.3880]
docker compose exec -it openmrsdb mysql -V
mysql Ver 8.0.37 for Linux on x86_64 (MySQL Community Server - GPL)
Now with no changes - the openmrs initializer does not go through. docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 2ddbce164d13 bahmni/openmrs:latest “/usr/bin/tini – ./…” 2 hours ago Up 2 hours 8080/tcp bahmni-standard-openmrs-1 7ed2d7a1675a bahmni/openmrs-db:1.0.0-standard-beta “docker-entrypoint.s…” 2 hours ago Up 2 hours 3306/tcp, 33060/tcp bahmni-standard-openmrsdb-1
docker logs 2ddbce164d13
at org.openmrs.util.DatabaseUpdater.executeChangelog(DatabaseUpdater.java:188) ~[openmrs-api-2.5.12.jar:?]
... 2 more
Caused by: liquibase.exception.MigrationFailedException: Migration failed for change set liquibase-update-to-latest.xml::1::upul: Reason: liquibase.exception.DatabaseException: Table ‘openmrs.person_attribute_type’ doesn’t exist [Failed SQL: (1146) ALTER TABLE openmrs.person_attribute_type ADD edit_privilege VARCHAR(255) NULL]
Finally succeeded in migrating our Centos based Bahmni to the docker container with just Bahmni core etc and Openmrs services up and running with the migrated database. Maybe I can I write up a note on my learning at a later time, since we are not all done. Our custom forms don’t show up. Form builder based changes need to be ‘migrated’? Any thoughts?