Post-migration cleanup
Remove the “(migrated)” names a Server-to-Cloud migration leaves behind.
The problem. A Server-to-Cloud migration renames anything that collides. Fields become “Impact (migrated)”. Roles become “Developers (migrated)”. It is a sensible thing for the migration tool to do, and a bad thing to keep. Two tools undo it.
Migrated Fields Cleaner
Choose the Cleanup Mode — Field Names, Field Descriptions or Field Configurations — then scan. The results table shows each field's ID, the configuration it belongs to, its current value and the cleaned value it will become.
You approve the exact rename before it happens. Nothing is renamed until you select rows and apply.
Migrated Fields Cleaner
Scan for Migrated FieldsRemove “(migrated)” tags from field names, descriptions and configurations after migration.
| ID | Configuration | Current Value | Cleaned Value | |
|---|---|---|---|---|
customfield_11890 | Default Field Configuration | Affected service (migrated) | Affected service | |
customfield_11902 | ITSM Field Configuration | Impact (migrated 2024-06) | Impact |
Migrated Project Roles Cleanup
The role equivalent, and it does more than rename. It removes the “migrated” suffix and moves the users and groups from the migrated role back into the original role.
That second half is the step people skip, which is why permissions stay split across two nearly identical roles for years.
- 1Choose where to look: permission schemes, projects, workflows, or projects and permission schemes together. A migrated role can be referenced in all three, and they are worth clearing in that order.
- 2Scan to find migrated roles and their members.
- 3Decide what happens to the migrated role itself: copy leaves it in place with its members, or move empties it of the actors it can prove came from the migration. Copy first if you are not certain.
- 4Review which members will move into which original role.
- 5Apply the cleanup to the roles you selected.