Migration Events — Clarity Migrate Docs

Overview

A Migration Event is the top-level container for a migration project in Clarity Migrate. It defines the project timeline — start date, go-live date, and end date — and groups all associated move groups, runbooks, assets, and T-Minus actions together under a single record.

Every asset that will be migrated must eventually belong to a move group, and every move group must belong to a Migration Event. Without a Migration Event, nothing can be tracked or scheduled in the Command Centre.

The go-live date on a Migration Event is particularly important: it is the anchor date from which all T-Minus task offsets are calculated. If the go-live date changes, all T-Minus task due dates shift automatically.

When to Use

At the start of a new migration project — create the event container before creating move groups or assigning assets.
When adding a new migration wave — each wave typically has its own Migration Event with its own go-live date.
When go-live dates change — update the go-live date on the event and all T-Minus dates recalculate automatically.
When progressing through migration phases — update the Status field (Planning → In Progress → Completed) to reflect where the event is in its lifecycle.

Key Features

Timeline Anchor

The go-live date drives all T-Minus task scheduling for the event. Change the date once and all dependent tasks update.

Move Group Container

All move groups and their assets are nested within an event, keeping migration scope clearly defined and bounded.

Status Lifecycle

Track each event through Planning, In Progress, Completed, or On Hold to reflect its real-world phase.

Ownership

Assign an Owner to every event for clear accountability. The owner receives notifications for key milestones and risks.

CSV Export

Export the full event list to CSV for reporting, stakeholder packs, or importing into external project management tools.

Executive Reporting

Event names and descriptions appear in executive summary reports. Keep them accurate for professional outputs.

Step-by-Step Instructions

Create a new Migration Event

Navigate to Migrations → Events. Click Add Event in the top-right corner. The event creation form opens. Fill in the Event Name, Start Date, Go-Live Date, End Date, Status, Owner, and Description. Click Save to create the event. It will appear immediately in the Events list and in the Command Centre.

Edit an existing Migration Event

In the Events list (Migrations → Events), find the event you want to update. Click the Edit button (pencil icon) on the right side of the row. Make your changes in the edit form and click Save. Changes take effect immediately across the Command Centre and all related views.

Update event status

Open the event edit form (see step 2). Change the Status dropdown to reflect the current phase — for example, change from Planning to In Progress when cut-over execution begins, or to Completed once the event is fully signed off. Keep status current so the Command Centre reflects real-world state.

View all move groups for an event

In the Events list, click on the Event Name (not the Edit button) to open the event's detail view. This shows all move groups nested within the event, with their progress bars, asset counts, and go-live dates. From here you can navigate into any individual move group.

Export the event list to CSV

In the Events list view, click the Export button (or the CSV icon in the DataTable toolbar). The full event list — including all visible columns — is exported as a .csv file to your Downloads folder. You can filter the list before exporting to scope the output to specific events or statuses.

Fields Reference

Field	Required	Description
Event Namerequired	Yes	A clear, unique name for this migration event. Appears in the Command Centre, reports, and all related records. Use a consistent convention such as `Wave N — Source to Target`.
Start Daterequired	Yes	The date on which planning and preparation activities formally begin. Used in the Timeline view.
Go-Live Daterequired	Yes	The target date and time for migration cut-over (T-Day). All T-Minus task offsets are calculated relative to this date. Critical — must be accurate.
End Daterequired	Yes	The date by which all post-migration validation and sign-off activities should be complete. Used in the Timeline view.
Statusrequired	Yes	Current lifecycle phase. Options: `Planning`, `In Progress`, `Completed`, `On Hold`. Keep this updated — stale statuses reduce Command Centre accuracy.
Ownerrequired	Yes	The person responsible for this migration event. Receives notifications for risks and milestone alerts. Should be a named individual, not a team.
Descriptionoptional	No	Free-text description of the migration scope — what systems are being migrated, from where, to where, and any key context. Appears in executive summary reports. Keep it accurate and up to date.

Example Workflow

Creating an Event for Wave 1 — Finance and HR Server Migration

A migration PM is about to kick off the first wave of a large datacenter-to-cloud migration. She navigates to Migrations → Events and clicks Add Event.

She fills in the form: Event Name = Wave 1 — Datacentre A to Cloud, Start Date = 1 February, Go-Live Date = 15 March at 22:00, End Date = 22 March. She sets Status to Planning and assigns herself as Owner.

In the Description field she writes: "Wave 1 covers 45 servers in the Finance and HR departments. Migration from on-premise Datacentre A to Azure East US. Target environment has been provisioned and validated."

She saves the event. It immediately appears in the Events list and is visible in the Command Centre Timeline. She then creates four move groups within this event to break the 45 servers into manageable batches.

Three weeks later, the customer requests a two-week delay to the go-live date. She edits the event and changes Go-Live Date to 29 March at 22:00. All T-Minus tasks for this event automatically recalculate their due dates based on the new anchor date.

Tips

Getting the most from Migration Events

Use a consistent naming convention. A format like Wave N — Source to Target makes events immediately identifiable in lists, reports, and the Command Centre. Avoid vague names like "Server Migration Q1".

Set the go-live date accurately from day one. T-Minus actions are triggered relative to this date. An inaccurate go-live date means your preparation timeline is wrong from the start. It is far better to set an estimated date and update it as plans firm up than to leave it blank.

Use the Description field seriously. The event description appears in executive reporting packs. A clear scope statement — what's migrating, from where, to where — saves time in stakeholder meetings and avoids scope confusion.

Update status as the event progresses. Events stuck in "Planning" status when they are actively executing cause confusion in the Command Centre and in reports. Build the habit of updating status at each phase transition.

Common Mistakes

Avoid these common mistakes

Creating an event without a go-live date. This is the single most damaging mistake. Without a go-live date, the T-Minus framework cannot schedule any preparation tasks, and the Command Centre Timeline cannot position the event correctly. Always set a go-live date, even if it is provisional.

Using vague event names. Names like "Migration Project" or "Q2 Wave" are meaningless in a large programme with multiple concurrent events. Use specific names that identify the source environment, target environment, and wave number.

Not updating status when events progress. Events sitting in "Planning" status when they are live, or sitting in "In Progress" status weeks after completion, make the Command Centre unreliable and erode team confidence in the data. Status updates take 30 seconds — make them a habit.