Migrate existing service desk issues to tickets

For both SaaS and Self-Managed customers, migrate all Service Desk Issues to the work item type Ticket.

1. Scheduled for 17.8.
2. Because Service Desk issues and tickets use the same underlying data structure, we don't need to migrate data from one table to the other.
3. We only need to change the work item type of all legacy Service Desk issues.
4. This will require a batched background migration that collects all legacy Service Desk issues (from support bot Users::Internal.support-bot and service_desk_reply_to NOT NULL) and changes the work item type to ticket.
5. For gitlab.com we can do this whenever we want to.
6. For Self-Managed we aim for the 17.8 release because this should be a required stop.
7. We can handle all post-migration operations after the required stop in 17.9 and following.

Success Criteria

• There should be no change in the UI
• Where Service Desk issues previously showed up, issues list, Service Desk list, boards, related issues, references, they continue to show up
• Tickets maintain all their metadata: assignee, labels, epic, etc

added to epic &10772

added Category:Service Desk grouprespond maintenancerefactor typemaintenance labels

added devopsmonitor sectionops labels

changed the description

mentioned in epic &10772

changed milestone to %16.2

added sectionsec label and removed sectionops label

added priority1 label

added priority2 label and removed priority1 label

added priority1 label and removed priority2 label

Relevant thread: &10772 (comment 1419009003)

mentioned in issue gitlab-org/monitor/respond#250 (closed)

mentioned in issue gitlab-org/monitor/respond#251 (closed)

mentioned in issue gitlab-org/monitor/respond#252 (closed)

mentioned in issue gitlab-org/monitor/respond#254 (closed)

changed milestone to %16.3

mentioned in issue gitlab-org/monitor/respond#255 (closed)

mentioned in issue #414314

mentioned in issue gitlab-org/monitor/respond#260 (closed)

mentioned in issue #415993 (closed)

mentioned in issue gitlab-org/monitor/respond#263 (closed)

mentioned in issue #421280 (closed)

@ck3g I'm wondering what the sequencing looks like for the migration on GitLab.com. When would it actually run? For example:

1. Aug 16th - MR that introduces the migration is merged (in 16.3)
2. Aug 16th - Migration starts running on GitLab.com (right after the merged MR reaches prod)
3. Aug 22nd - 16.3 is released. Self-managed customers who upgrade will need to stop at 16.3 and the migration will be triggered at that time.
4. Aug 23rd - Migration is complete on GitLab.com (in this example let's say it takes 7 days)

Is that correct?

We just had a brainstorming session with @francoisrose and here are the steps we need to do.

One of the main requirements we should meet is that we need to ensure there are no legacy issues created after we run the migration of legacy issues to tickets. Otherwise, we would need to run the migration again.

The outcome we had with @francoisrose ended up the same as Sarah's plan here &10772 (comment 1433165942)

I would confirm the steps anyway:

1. We introduce a new ticket type !127482 (merged)
2. We start creating tickets from service desk emails.
   • At the same time, we ensure that we display both issues and tickets on the /service_desk page. In that case, we will not hide any data.
3. We migrate issues created by User.support_bot to issue_type=ticket
4. We start adding features behind a feature flag.

@ck3g FYI I created an issue for step 2 since I couldn't find one: #421727

@francoisrose FYI

I've just noticed that we cannot covert issues to tickets if an issue has an epic assigned. https://gitlab.com/gitlab-org/gitlab/-/blob/03da2402f38bb5a14f03b48f6dfeb02e5d0f9d1a/ee/app/models/ee/issue.rb#L356-365

So we may need to start supporting epics for tickets before we do a migration (point 3). That shouldn't be a problem, since we're planning to make tickets and issues to work at the same time. But that postpones the migration.

@ck3g understood, thanks for raising this. One issue I see is we need alignment with groupproduct planning on allowing Epic (parent):Ticket (child) relationships (see [1] and [2]) before we can implement it. I'll post in that thread to raise this.

Thinking ahead a bit, I see 2 possible outcomes:

1. Decision: Tickets can be children of Epics
   1. Option 1: implement the Epic:Ticket relationship before the migration
   2. Option 2: add Tickets as an exception to the rule you linked (cf comment in code), proceed with migration before implementing Epic:Ticket
2. Decision: Tickets can NOT be children of Epics
   1. Option 1: hard breaking change: migrate and lose the Epic relationship
   2. Option 2: soft breaking change: migrate and link Tickets to their previously assigned Epics (can we do that as part of the migration?)

mentioned in issue gitlab-org/monitor/respond#264 (closed)

marked this issue as blocked by #421727

marked this issue as blocked by #420862 (closed)

mentioned in epic &6286 (closed)

changed the description

changed milestone to %16.4

added missed:16.3 label

changed milestone to %Backlog

mentioned in issue #426002 (closed)

changed milestone to %17.8

added devopsplan groupproject management sectiondev labels and removed devopsmonitor grouprespond sectionsec labels

assigned to @msaleiko

set weight to 3

mentioned in epic gitlab-org#10772

changed the description

changed milestone to %Backlog