Ex-Employees & Missing Users

One of the most common challenges in enterprise migrations is dealing with work items assigned to people who have since left the organisation. This is especially common in projects with years of history.

Resolution Strategy

During Phase 1 (preflight), Migrayt loads the complete Jira user directory and cross-references every ADO user email found in the project. For each missing user, it attempts the following steps in order:

Step 1 — Find in Jira directory

Migrayt searches the Jira user directory for an exact email match. If found, the user is mapped directly and no further action is needed.

Step 2 — Create an inactive account

If the user is not found in Jira, Migrayt attempts to create a directory-only account:

POST /rest/api/3/user
{
  "emailAddress": "alice@company.com",
  "displayName":  "Alice Smith (Former)",
  "products":     []
}

The products: [] field means the account exists in the Jira user directory but has no product access — the person cannot log in. The account can be assigned issues, mentioned in comments, and searched, but cannot actually use Jira.

This is the preferred outcome. All items are assigned correctly, and if the employee returns or the account needs to be activated, a Jira admin can enable product access.

Step 3 — Ghost account (fallback)

If account creation is blocked (e.g. because your organisation uses SSO/SCIM and user provisioning is centrally managed), Migrayt falls back to a ghost strategy:

1. The work item is assigned to the migration service account
2. The original assignee's name is prepended to the issue description:

   [Originally assigned to: Alice Smith (alice@company.com)]
   
   [Original description follows]
   ...
3. For comments, the attribution header includes the original author name regardless of Jira account status.
4. For time logs (7pace add-on), entries are written under the migration service account with the original author in the comment body.

Summary in the Report

After migration, the post-migration report includes a section summarising user resolution:

User Resolution
───────────────────────────────────────────────────────────
Active users mapped:     187    (found in Jira directory)
Inactive accounts created: 12   (ex-employees, no login access)
Ghost assignments:          3   (SSO-managed, could not be created)
  - alice@company.com        → 34 items reassigned to migration account
  - bob@company.com          → 8 items reassigned to migration account
  - charlie@company.com      → 2 items reassigned to migration account

What to do after migration

For ghost-assigned items, you have two options:

1. Reassign in Jira — Use Jira's bulk edit to reassign items from the migration account to the correct current assignee.
2. Create the accounts manually — A Jira admin can create inactive accounts for the ex-employees and use Jira's bulk edit to reassign.

The ghost items are easily identifiable because they are assigned to the migration service account and have the [Originally assigned to: ...] note in the description.