We are looking to develop and document a migration strategy /path that can be used by the community to seamlessly ( both ways) move from one version of OpenMRS to the other. In order to do that, there are a number of considerations that need to be taken into account which we would explore and understand better. These include:
What are the technical issues that affect current migration in OpenMRS
What are the environments in which these migrations are currently being done/ attempted?
Is the intention to migrate the whole application or just critical parts of it?
What are some of the migration scenarios that could/ are occurring?
What is the contingency plan if the migration does not go well? (Including scenarios?)
Please do leave your thoughts in the this talk thread.
IMO this depends on the level of customization within the implementation. If best practices are followed, just like we did for UgandaEMR, we moved from 1.6.3 -> 1.9 -> 1.11.x -> 2.0.6 without major headaches
The 1.6.3 -> 1.11.x required SQL scripts since the OpenMRS liquibase upgrade process was too slow
1.11.x -> 2.0.6 required changing the Java platform version from 7 to 8, but no changes
Maybe a question, rather than a migration strategy shouldn’t the focus be on providing more value to new OpenMRS platform & Reference Application versions so that this becomes important due to a huge rush to get there?
Currently there is nothing major warranting the need to migrate
Agreed Stephen. Migration strategy must include a new ‘thing’ with such great functionality that it outweighs the pain to migrate to get there to use it
Ensuring there’s a well-documented process to migrate between OpenMRS versions is a laudable goal, but also a huge task. I would offer to suggestions:
Solve an actual problem. Who wants to upgrade but is struggling/failing for lack of documentation? Start there. Avoid documenting how to go from 1.11.x → 2.0.6 when 80% of people who would like to upgrade want to go from 1.6.3 → 1.11.x.
Make sure to include foot soldiers. Helping people successfully migrate and generating re-usable documentation as a side effect will vastly increase the likelihood that the documentation will be useful for the next person. There are often real world implementation issues to be addressed (e.g., how to prepare a clinic for the upgrade, how to anticipate downtime, coordinating upgrades when you have dozens of remote clinics running OpenMRS and some are running different versions of modules, etc.).
Thanks for helping push on this effort, since neither a well-documented upgrade path or a new “thing” to make the upgrade worthwhile are sufficient. We need both.
