Procedure and tooling for changing the hierarchy of an existing application #6751
Labels
Migrations
Affects data migrations
Priority: 2 - Medium
Normal priority
Status: Blocked waiting for info
Blocked waiting for more information
Type: Improvement
Make something better
Type: Investigation
analyzing or researching for product planning (no dev required)
What feature do you want to improve?
A CHT application's hierarchy is foundational and not easily changed once the project goes live. Hierarchy data exists in every contact, every report, etc. Whenever possible, applications try never to change the hierarchy once the application is live. But sometimes hierarchies must change. In our 2021 SoWs, multiple projects include deliverables which require hierarchy changes including BRAC (3000 CHWs and 16M docs) and Siaya.
Hierarchy changes require the majority of documents to be re-synced, and sometimes require the user to clear all documents from the phone. They can result in data-loss or invalid data due to clearing the device before syncing, or making the server-side hierarchy change before syncing reports which will still have the legacy hierarchy within them. Because of data-loss risks, heirarchy changes can be associated with down-time.
Because of the above factors, need to be tightly coordinated with teams on the ground and therefore carry intense operational burdens. Due to operational burdens, they often are requested to happen in phases.
Describe the improvement you'd like
At a minimum, we need clearly documented repeatable steps to execute hierarchy changes at scale without data loss. We need these steps to be fast and easy enough that we can complete migrations for projects with thousands of users in 2021 Q2 latest so we can complete the rest of the SOW in 2021. It is recommended that we investigate core improvements or tooling improvements which ease the operational burdens on the ground and minimise the risk of data loss .
The text was updated successfully, but these errors were encountered: