/
Migration Constraints

Migration Constraints

This document identifies and describes the main technical and product limitations related to the progressive migration from the current user grouping mechanisms (Cohorts, Teams, and Enrollment Tracks) to a unified, criteria-based system. The goal is to anticipate risks, constraints, and areas that require further exploration.

Limitations by User Group

1. Cohorts

  • Embedded automatic assignment logic: The automatic assignment logic for cohorts is tightly integrated into the course content access flow. Migrating this functionality to the new model will require refactoring and decoupling that logic.

  • Database persistence: The current model does not allow cohort deletion—only the complete deactivation of the functionality.

  • Dependency on partitions: Content restriction relies on the cohort-based partition scheme.

  • Discussion visibility: Cohort-based segmentation in forums is strongly tied to the current model and will require dedicated support in the new system.

  • Assignment of unregistered users: The ability to assign users who are not yet enrolled or who do not have an account must be validated within the new group creation flow.

2. Teams

  • Integration with ORA: The current system allows ORA tasks to be linked to a specific team set. This integration depends on a direct connection between the team-set identifier and the ORA evaluation component.

  • User limit per team: The current mechanism limits the number of users to a maximum of 500 per team.

  • Two-level grouping: Teams use a two-tier grouping structure (team-sets and teams). This hierarchical behavior may be challenging to replicate within the unified model.

  • Team-set types: There are several team-set types (e.g., open, public_managed, etc.) with distinct behavior logic that may not directly map to the new model.

3. Enrollment Tracks

Unlike the previous models, replicating the current behavior is relatively straightforward, as this grouping is purely based on the enrollment track used to segment content.

  • Dependency on partitions: Content restriction relies on the enrollment-track-based partition scheme.

4. General Migration Process Limitations

  • Bidirectional synchronization: During the intermediate migration phase, it is necessary to maintain sync between the legacy and new models, introducing operational complexity and the risk of inconsistencies.

  • Backward compatibility: Existing integrations (e.g., external APIs, XBlocks) may fail if legacy models are not accurately simulated.