Modular Migration: Open Issues
Contents
On this page we collect migration issues that will still have to be looked at for a full migration to the Target Technology Stack .
Current Migration Projects
Custom Modifications
Impact: depends, will have to be collected per country by implementation partners
push for customizations based on module configuration
Custom Modifications in Nepal
Project: Modular Migration Nepal - warning about project success due to budget constraints
(tender in preparation as part of a general openIMIS maintenance contract) : Swiss TPH
a lot of custom functionality: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43
establish list of functions that need to be migrated
prio 1: existing modification in legacy / hybrid version: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43
prio 2: new feature requests (must)
prio 3: new feature request (nice to have)
develop:
migration of database structure
prio 1: existing modification in legacy / hybrid version: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43
claim
enrolment
configuration
reports
mark mandatory fields - might be possible to do afterwards ONI-120: Design and implement a way to show warnings about unmet requirements during savingCancelled
prio 2: new feature requests (must)
reports - migration of current system to DHIS2
prio 3: new feature request (nice to have)
Custom Modifications in Tanzania
budget discussion might not allow a migration within the current contract - future strategy in TZ unclear
payment layer through REST API - dedicated API for GePG (Government ePayment Gateway)
MUSE API exists (will not be changed) - fully based on modular version
GoThomis - will TZ move to FHIR? (budget)
AfyaCare - will TZ move to FHIR? (budget)
GePG API exits in legacy
needs to be migrated to modular architecture (as a custom API)
capitation payment,
commission
Covered by Project: 2022.T1c Modularisation III :
GePG not covered for the implementation in TZ, but support in global components might be possible
mobile apps on REST API is migrated to FHIR APIshttps://docs.google.com/spreadsheets/d/1XdamXxLejmPRzM5xN8dCSPSIbfNv1PgJ/edit#gid=1496686413
The apps are being adapted so that the API calls can be dispatched to one interface or another
Meeting to be organized with Christophe/Benjamin and STPH to see what can be done for the payment parts
specific reports → migrate to ReportBro https://docs.google.com/spreadsheets/d/1ORCdW5qajBbDT4BaKmAKf6W7X4wbs2Rcd0EQNEVRRzQ/edit?usp=sharing
Download master data (claim mobile app)
list of beneficiaries
Scheme Funding (“Matching Funds“)- distribution per region (currently done via fake families)
The code is there but was disabled some time ago
Could be done
…
capitation payment configuration in Product
batch run
capitation payment SP
batch run SP
Custom Modifications in Cameroon
HIV
report on migration needs done by STPH (-> Implementers) - covered in Project: Customization Cameroon
EDUCASH
Cash-Transfer scheme => to be migrated to modular?
Custom Modifications in Gambia
Cash-Transfer scheme is in progress of migration
Custom Modifications in Niue
Cash-Transfer scheme is in progress of migration
REST API
Impact:
Mobile Apps will not work any more
GOTHOMIS & Payment Layer in TZ
stuck to MS SQL because of stored procedures that are called from REST API (ca. 45)
Discussion:
C#-part can be re-used, but depend on stored procedures → will be migrated
- needs to be compiled for .net core per Windows and Linux (done in Docker)
- Added to Docker packaging
- issue with env variables (ex. DB connection string)
- sharing of files (ex. Insuree pictures)
- Test REST API against PostgreSQL - not practical as REST-API will not be migrated on PostgreSQL
list of interactions with DB: https://docs.google.com/spreadsheets/d/1XdamXxLejmPRzM5xN8dCSPSIbfNv1PgJ/edit#gid=1496686413 - will not be needed after
mobile app for claims
mobile app for registration
Stored Procedures
Impact: depends
Discussion: need to list remaining stored procedures that will not be migrated
https://docs.google.com/spreadsheets/d/18XxbBsPXvHrq7Enu7Bj02WpE1GiIaslNP1aMK6ECQcU/edit#gid=0
Lock Mechanism
will need to be migrated to PostgreSQL?
testing - PostgesSQL uses low isolation level by default - might solve the problem
needs large data DB
in combination with report migration
develop.openimis.org
might not be needed, documentation on how to approach potential problems
MS-SQL Driver in Django
Impact:
Custom Access to MS-SQL DB
affects JSON-B column access
hinders upgrade to Django 4
Discussion:
only a problem as long as s.o. is using MS SQL
maybe there are new drivers
solved - there is an official MS driver for Django now
DB-Initialisation Script
Impact:
new installations (new, empty DB) not yet using all attributes
migration script need to know DB version to adjust to all scenarios
Discussion:
https://openimis.atlassian.net/wiki/spaces/OP/pages/3380871169
DB - initialisation:
two separate INIT scripts for PostgreSQL & MS SQL available
legacy migration:
migration script for the legacy data available
future development will be against PostgreSQL
other DB will have to use Django Migration scripts to fork to their DB system (automatically through Django “make migration“ - might need manual adaptations)
documentation needed
most is done automatically at startup
create a link in each release note point at a migration path for that version with manual exceptions
testing of the documentation is needed
Reports
List of reports: Wiki: https://openimis.atlassian.net/wiki/spaces/OP/pages/3361669121, migration status: https://docs.google.com/spreadsheets/d/1ORCdW5qajBbDT4BaKmAKf6W7X4wbs2Rcd0EQNEVRRzQ/edit?usp=sharing
which reports still need to be migrated? which ones are still used?
some reports don’t work
list of reports to all sites with feedback on what they are still using (no nice-to-haves!)
also have a look at https://www.metabase.com/start/oss/
migration of reports
use of Kibana and OpenSearch in the context of CORE-MIS migration is out of scope
Documentation How-To / Best-Practices of Migration
Did you encounter a problem or do you have a suggestion?
Please contact our Service Desk
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/