As part of the ticket - SB-9803, we are required to merge user/content of 2 tenants into 1. Earlier the state had created 2 tenants, both have users as well as content. There may be user-org associations in both tenants as well. As part of this story we need to migrate the data from one tenant to other, and then retire/close/delete the empty tenant.

We can provide a set of APIs using which one can migrate user, sub-org or content across the tenants (Root organization).

Pros

• User will not require the server access, can trigger API

• User can use different API's to build custom script, which is more flexible

• We can apply user-access control if it is considered as an API end-point.

• Does not require to bring the server down.

Cons

• It is a one-time administrative task, so providing API is little risky for such cases

• This API may not be useful for all users, and will bulk up the user-code unnecessarily.

• difficult to implement and more over-head considering it is one-time job.

Solution

API to migrate organisation

POST /v1/tenant/migrate - will migrate the sub-organizations, to point to new root-organization.

{ "sourceRootOrgId" : "0101201012", "targeRootOrgId" : "0101201013",
"entities" : ["user", "org", "content"]
"userIds" : ["id1", "id2" ] }

UserIds → if mentioned will be applicable to only those users, else to all users will be migrated.

entities → if mentioned only those will be migrated, else all entities will gt migrated.

Responses

200 OK - both valid root-org are provided and data can be migrated

400 Bad Request - Invalid sourceRootOrgId or targetRootOrgId

• any of the org does not exist

• any of the org is not active

• any of the org is not a root-organization

Above API's will individually migrate the individual data

Provide a stand-alone script/migration job, which once invoked will migrate the data internally, with minimal user choices.

Pros

• Simple approach, easy to implement

• We do not have to expose such changes as API, as this is admin type of activity

Cons

• Very specific solution - not much configurable from user perspective

• User requires access to environment, as process will be run from background using environment variables.

• This requires that server. instance must be down, while we are doing this migrations.

• Child organization - Root org - may have other child organizations, we need to migrate those child organizations

• User's root-org need to be updated to new root-org

• Content data - channel name - need to be migrated according to new channel name.

• User-org association, for old root-org need to be deleted, and new user-org association need to be added

• geo_location data - which refers the root-org id also need to be migrated

• badge_class_extension - also refers to the root-org

• There are several storage structures which point to organisationid which need to be migrated if they are pointing to root-org which is being migrated.

  • course_management (organisationid, organisationname)

  • user_org(organisationid)

  • page_management (organisationid)

  • bulk_upload_process(organisationid)

• Get all user ids for Rajasthan Pilot Organisation

• Update the rootOrgId, channel & slug for user ids fetched in above step.

• Get all user-org entries where associated org id is Rajasthan Pilot.

• Update the rootOrgId to point to Rajasthan root org.

• Sync the users updated to ElasticSearch index

• Get all course batches where createdFor is pointing to Rajasthan Pilot

• Update the course batches and set createdFor to Rajasthan

• Sync the course batch details to ElasticSearch index.

• Mark the Rajasthan Pilot Org → inactive status.

• Telemetry data will be pointing to according to old values for all the updates made so far, and will not be migrated.