Platform Switching
Part of Switching project management platforms
Mapping old task statuses into a new system
Preserve the meaning of open, waiting, review and completed work when mapping task statuses during a platform migration.
Map old task statuses by what they mean for the next action, not by matching names or colours. Record each source value and its meaning, choose the destination treatment, then check that open, waiting, review and completed work appear in the right queues and reports.
Record the source meaning
Ask project leads when a task entered and left each old state. “Review” might mean work has been submitted, accepted or merely booked for a meeting; these meanings need different destination treatment. Keep completion separate from approval where acceptance is required.
A mapping sheet should include the source value, entry and exit rule, destination value, next owner and exception rule. If someone will need to explain the conversion later, preserve the source value in a reference field or note.
| Hypothetical old state | Meaning to check | Possible treatment |
|---|---|---|
| Doing | Someone is working on it | In progress, if the next owner is known |
| Waiting | Work cannot advance | Waiting, with reason and resolver |
| Ready for sign-off | Output has been submitted | Review, with a named approver |
| Closed | Work ended | Completed only after checking why it closed |
This is an example, not a universal workflow. A rejected request and an accepted deliverable might both be “Closed” in the old system; preserve the difference in the destination record.
Check what the import route does with structure
Import routes can treat source structure differently. For each route, check the current importer documentation and available options to determine how source states and groupings will be represented. Do not assume a column, section or group becomes a destination status.
Before importing, review how each incoming status value is mapped or handled by the selected route. After import, inspect records to confirm that destination values preserve intended meaning. Documentation about importer mechanics alone cannot establish that a team's chosen mappings are correct.
Check the queues people use
Select a task from every old state, plus a returned review, a cancelled item and an item with no status. After import, check the task and the filters or dashboards used for daily work. A record may exist yet be absent from the queue where someone expects it. Confirm that completed work is not counted as open and work awaiting approval is not reported as accepted.
Give ambiguous values to a project lead for a decision. Avoid creating destination statuses solely to preserve old wording. If a label conveyed a reason rather than a stage, retain the reason in a field or note and map the stage separately. Agree the mapping before active work moves, then reconcile exceptions after import.
