Move Groups
The primary unit of migration execution. Move Groups define logical batches of assets migrated together in a single wave, each with its own go-live date, owner, and progress tracking.
Overview
A Move Group is a logical batch of assets — devices, applications, or databases — that are migrated together during a single execution window. Move Groups sit beneath a Migration Event and are the primary unit against which progress is tracked, runbooks are executed, and capacity is planned.
Every asset that is to be tracked in the Command Centre must be assigned to a Move Group. An asset without a Move Group assignment appears as unplanned in CMDB views but will not appear in migration progress tracking.
Move Groups can be created with different go-live times within the same Migration Event, allowing you to stagger execution in batches rather than migrating everything simultaneously. This is the recommended approach for large migration events.
When to Use
- Breaking a migration into waves or batches — create one Move Group per batch, with its own execution window.
- Assigning assets to migration windows — use the Move Group Picker or the device record's Migration Plan field to assign assets.
- Tracking per-batch progress — the Command Centre shows progress bars per Move Group, making it easy to see which batches are on track.
- Linking runbooks to specific batches — a runbook can be linked to a Move Group so its tasks appear in the correct section of the Command Centre.
- Capacity planning — Move Groups feed into capacity planning calculations, letting you model the load each batch places on target infrastructure.
Key Features
Graph View
Switch from the table to the Graph view using the Graph button in the toolbar. The graph shows the full dependency blast radius for the selected Move Group — all applications, devices, and databases that are connected to it, both within the group and outside it.
Graph Key
| Symbol | Meaning |
|---|---|
| Application icon | Application node |
| Device icon | Device (server / VM) |
| Database icon | Database instance |
| Amber thick border | External — belongs to a different Move Group or is unassigned |
| Dashed red line | Cross-boundary relationship — migration risk |
Right-click any node or connection in the graph to open a details panel showing the asset's full record or the relationship's port, protocol, bandwidth, and latency data.
The graph shows only applications, devices, and databases. Hypervisor infrastructure (ESX hosts, clusters, datacentres) is excluded because those assets are infrastructure that moves transparently — they are not migration planning items in their own right.
Step-by-Step Instructions
Navigate to Migrations → Move Groups and click Add Move Group. In the form, select the parent Event, enter a Move Group Name (e.g. MG-001 Web Servers), set the Go-Live Date, assign an Owner, and set Status to Planning. Click Save.
Open the Move Group record by clicking its name in the list. Click the Add Assets button in the Assets section. The Move Group Picker opens — use the search box to find devices, applications, or databases by name or ID. Select the assets you want to add and click Assign to Group. The assets are immediately linked to the Move Group and appear in the Command Centre.
Open the device record in CMDB → Devices. Find the Migration Plan field in the Migration section. Click the field and select the destination Move Group from the dropdown. Save the device record. The device is now assigned to that Move Group and will appear in its asset count.
Navigate to CMDB → Devices. Use filters to narrow the list to the assets you want to assign (e.g. filter by environment, team, or tag). Select multiple rows using the checkboxes. Click Bulk Edit in the toolbar. Set the Migration Plan field to the target Move Group and confirm. All selected devices are assigned in one operation.
Click the Edit button on a Move Group row (or open the record and click Edit). Change the Status field to reflect the current phase: Planning → Ready → In Progress → Completed. Update status to Ready before a cut-over window to confirm the group is fully prepared. Update to In Progress when execution begins, and Completed once all tasks are done and sign-off is obtained.
Navigate to Migrations → Move Groups → Summary. This view shows all Move Groups across all events in a single table, including their asset count, runbook assignment status, go-live date, and current status. Use it to quickly identify groups that have assets assigned but no runbook linked — these will execute without a tracked procedure.
Fields Reference
| Field | Required | Description |
|---|---|---|
| Move Group Namerequired | Yes | A unique, descriptive name for this batch. Recommended format: MG-NNN Description (e.g. MG-001 Web Servers). Appears throughout the Command Centre and in reports. |
| Eventrequired | Yes | The parent Migration Event this group belongs to. All Move Groups must belong to an event. Cannot be changed after assets are assigned. |
| Go-Live Daterequired | Yes | The target date and time for this batch's cut-over window. Can be different from other Move Groups in the same event to enable staggered execution. |
| Ownerrequired | Yes | The named individual responsible for this Move Group's execution. Should be the engineer leading the cut-over, not the project manager. |
| Statusrequired | Yes | Current phase: Planning, Ready, In Progress, or Completed. Must be updated to Ready before cut-over to confirm preparation is complete. |
| Descriptionoptional | No | Free-text notes about this batch — what it contains, any specific execution constraints, or special instructions. Useful context for engineers who may not be familiar with the scope. |
Example Workflow
An engineer is planning Wave 1, which covers 35 devices across four technology layers. She creates four Move Groups within the Wave 1 — Datacentre A to Cloud event:
MG-001 Web Servers (go-live 22:00), MG-002 App Servers (go-live 22:30), MG-003 Databases (go-live 23:00), MG-004 Test Systems (go-live 23:30). Staggering go-live times by 30 minutes each means a problem in one layer doesn't automatically block the next.
She uses the Move Group Picker to assign 8 web servers to MG-001, 12 app servers to MG-002, 5 databases to MG-003, and 10 test servers to MG-004. Total: 35 assets assigned across 4 groups.
She then navigates to the Move Group Summary and confirms that all four groups show the correct asset counts. She notices that MG-003 Databases has no runbook linked. She creates a runbook for it and links it to the group before proceeding.
Tips
Keep Move Groups small. Aim for 8–15 assets per group. Smaller groups are easier to execute, easier to roll back if something goes wrong, and easier to track in the Command Centre. A single group with 80 assets is a recipe for a chaotic cut-over night.
Use the Move Group Summary before cut-over. Navigate to the Summary view and check that every group has at least one runbook linked. Groups with assets but no runbook will execute without tracked procedures — a significant governance risk.
Stagger go-live times within an event. Even 30–60 minutes between groups gives the team time to validate each batch before starting the next. It also means a failure in one group doesn't delay work on independent groups.
Update status to Ready at least 24 hours before go-live. This confirms that preparation is complete and gives stakeholders confidence. If a group cannot be moved to Ready status, it likely has unresolved issues that need attention.
Common Mistakes
Creating one giant Move Group with all assets. Migrating 80 servers as a single batch means a single point of failure during execution. If something goes wrong, the entire wave is at risk. Break large migrations into smaller, independent groups that can be executed and validated sequentially.
Not setting a go-live date on Move Groups. Move Group go-live dates appear in the Command Centre Timeline and are used by capacity planning. Without them, your scheduling view is incomplete and capacity calculations may be wrong.
Forgetting to update status from Planning to Ready before cut-over. A group in Planning status during a live cut-over signals to the team that preparation may not be complete. Build a pre-cut-over checklist that includes updating all group statuses to Ready as a gate criterion.