Implementer's Checklist for Modular Migration

This checklist is intended to act as an orientation for current implementers and users of openIMIS to plan migration from their legacy to new modular version of openIMIS. There is another checklist provided from the perspective of developers embarking on the migration but the purpose of this page is to provide a reference point for implementers and users of openIMIS.

Step 1: Understanding the need and urgency of migrating to Modular version

The fist step as an implementer and user of openIMIS is to understand the value of migrating from legacy to new modular version and why it is essential to do so soon. The openIMIS global initiative currently supports the maintenance of the legacy version along with supporting the development of the new modular version of openIMIS. Now that the new modular version has been fully developed / close to completion, the legacy version of openIMIS will no longer be maintained by the openIMIS Initiative after August 2022. Hence any issues on the legacy after this time frame will not be resolved by the programmers working under the openIMIS Initiative and your local implementation teams will need to manage them on their own. It is hence important for all countries using the openIMIS legacy version to undertake a migration from the legacy to the new modular version as soon as possible (ideally within this time frame). This migration would allow you to continue to benefit from the openIMIS global initiative in the future as the programmers working with the openIMIS Initiative will continue to undertake enhancements, fix bugs, create new modules and integration with other systems on the new modular version. All these enhancements to the openIMIS new modular version as well supporting resources will continue to be freely available to you under the same open source license and hence provide you benefits of being part of the global openIMIS community. Undertaking a migration from one technology stack to another is always time and resource consuming as well is a meticulous task requiring a lot of attention not just from programmers in your team but as well administrators, trainers and users involved in your respective implementations. Understanding and believing in the value of migrating is hence an important starting point for any implementation embarking on this journey. So as an implementer/user of openIMIS it is important to be clear about your reasons to migrate and the value you know the new modular version can add to your implementation. If you would have any further questions or would like to speak to the openIMIS Initiative Coordination Desk contact: contact@openimis.org

Step 2: Familiarization with Modular version

Once you have decided on migration, an important step is to first familiarize oneself with the new version. The new modular version of openIMIS is expected to be everything that you had with your legacy version of openIMIS and more. All functionality of the original legacy version has been transferred into the new modular version, though what might have changed for you is the interface through which you interact with these modules. i.e. how you enter a family or a claim into the system follows still the same logic but the buttons to Add or Save might have moved to another spot. The new modular version as well allows you more flexibility to modify these interfaces further to your own needs. Therefore while the screens might look different from your legacy version, the functionality remains the same and hence important that you first familiarize yourself with the new modular version and can assure yourself that this version can do the same and more than your legacy version. You can do this by going to the demo server and trying out the different functionalities here: Log In - openIMIS

Step 3: Feedback to Developers

It is also possible that you require further clarifications during your familiarization process and that you have more questions. Please feel free to reach out and raise any questions you might have to the openIMIS developers on XXXX. It is important to go through each module and check weather it fulfills the requirements of your scheme and has the same functionalities as in your legacy version. It is also helpful to undertake this step with your teams members who are well versed with using openIMIS in your implementation. They should undertake all processes and tasks they know are undertaken in running of your scheme. If you find that there are tasks that you are unable to undertake with the new modular version please raise this on the openIMIS service desk.

It is possible that you might find certain functionalities missing in the new modular version due to the fact that your implementation might have done some country specific changes to the software that were not contributed back to the openIMIS initiative. The openIMIS initiative has developed the new modular version as a reflection of the legacy version that they maintained in the past years, so in case country developments were not shared back with the Initiative, these changes might not be part of the new modular version. For example, if an additional field with some additional checks was added to the page which captures data of each individual in the legacy version of a country implementation and this was not indicated to the openIMIS initiative, then it will most likely not be present in the current modular version but would need to be re-done in the modular version. Therefore, implementers should be in contact with developers to communicate these needs to make sure that once the migration is complete, the future releases of the new modular version carry their country specific functionality so its available to you as well as other users. The following sub-steps should be followed:

• Go through all the processes of your scheme and identify gaps or developments that you find missing

• Clearly communicate these to the Initiative developers through the openIMIS Service Desk

• Ask your programmers to share the source code (if not already done) of your used version of openIMIS including any country specific changes that might have been undertaken to the Initiative developers through Github

• Discuss and identify with the openIMIS Initiative developers how your country specific changes are to be handled in future openIMIS new modular version releases (either integrated in the release or to be added by your programmers after deploying the new release

Step 4: User testing

Once you have ensured all your changes have been incorporated and that openIMIS new modular version can provide all functionality that you need for your implementation, then the next steps is to deploy and test the application at various levels within your implementation teams. Each openIMIS release is thoroughly tested as per the openIMIS testing plan but there is no replacement for real world testing of any software. Different users in your implementation use the openIMIS application in their own varying ways and hence having them test the application from their respective perspectives will help you build confidence that the new modular version can fulfill requirements of your scheme and improve its performance.

You should therefore organize a testing approach within your country implementation. Guidance on testing approaches and steps can be found here that the openIMIS Initiative endorses and can be used as a guide by country implementations. While these are extensive lists of tests you are encouraged to undertake as many of these functional and non functional test categories as possible.

User testing is highly recommended in this regard. The test cases for user testing for the modular version can be found here: User interface test - openIMIS - Confluence (atlassian.net. However, based on the country customizations, some test cases may need adaptations. It is also advised that beyond these test cases to ask different user groups to also undertake free testing from their perspectives beyond such a structured test cases list, to allow for opportunities to test the system from the perspective of different eyes.

In case you find any issues during your testing process that the Initiative developers should rectify or enhance please report them to the openIMIS Service Desk.

Step 5: User training

The main difference between the legacy and the modular version, from the point of view of the end user, is the interface. Indeed, colors, fonts, and certain tabs have changed and perhaps some features provide you with more flexibility which might also allow you to enhance your usage of openIMIS. So this would also be a good opportunity for you to review the way in which you are using openIMIS and in that regard also revise the way you want to train or rather retrain users on use of the new modular version of openIMIS. Therefore, an important step in the transition will be to conduct trainings to introduce different end user groups to the new interfaces. This will also mean consolidating and updating all training material and other documentation beforehand. The following sub-steps hence are useful to have at hand:

• Consolidate all existing material and documentation used for openIMIS

• Update existing training material and reference manuals with new interfaces (slides with interface screenshots, user manuals, practical exercises etc.).

• Re-organize trainings for different group of actors

Step 6: Step by step introduction (pilot and then scale up)

Once the new modular version is ready to be rolled out and gone through you own teams testing process and subsequent training of respective user groups it would be advisable to introduce the system in steps to allow for a gradual transition. As per your implementation realities it is possible that a one time complete transition and roll out is a better approach. Generally speaking though, it is useful as with any introduction of a new software, a new module or a prototype, to introduce the new solution in steps either geographically or by user groups or other categories that you might find as meaningful in your context. This would allow for gradual introduction and resolution of issues if they come up as well easier roll back that impacts lesser part of your operations in case of any major issues that you might observe.