Device Migration Overview

This chapter explains the core concepts and structure of Device Migration.

Device Migration concepts

Device Migration is a framework for enabling a structured approach for transferring services, device configuration, and live network traffic from an existing network device to a new one while preserving operational dependencies and traffic continuity throughout the migration.

How Device Migration works

Device Migration is driven by user-defined migration Methods of Procedure (MOPs). A MOP defines the sequence of actions and validations required for a specific migration scenario, enabling users to design migration logic that fits their network topology and service requirements.


Attention


Device Migration is not shipped with a pre-built MOP. Users must create their own MOP to perform specific tasks to facilitate the migration process.


Migration job and device coordination

Each migration runs as a single Device Migration job, which executes the selected MOP instance. All devices involved in the migration—including neighboring devices required for traffic rerouting or validation—operate within the same execution context. This ensures that inter-device dependencies are preserved and that configuration changes and traffic transitions are coordinated consistently.

Migration progression depends on the successful completion of the validations defined in the MOP.

User capabilities

Through the migration workflow application, users:

  • Create custom migration MOPs,

  • execute MOPs through a guided, pre-defined user flow, and

  • tailor migration logic to specific operational and service requirements

Device support

Device Migration supports a heterogeneous device environment and facilitates migrations involving different device types, as long as those devices are supported.

Execution model

Device Migration follows a fleet-wide execution model in which all migration MOP actions run within a shared execution context. Instead of operating as separate per-device tasks, migration actions are evaluated and executed with awareness of every device included in the migration plan.

A migration activity may target:

  • a single device, or

  • multiple devices simultaneously, depending on its definition.

This model enables coordinated behavior across the migration—for example, validating neighbor state before applying changes, or sequencing configuration updates across dependent devices. By evaluating MOP actions against the full set of participating devices, the system ensures that multi-device operations are executed predictably and in the intended order.

Device roles and labeling

Each device included in a Device Migration job is assigned a role. Device roles define how a device participates in the migration.


Important


You can add additional device labels if required. Predefined labels used by Device Migration cannot be removed. Multiple devices can use the same label.

You can add new custom labels by editing the Device Migration application (Administration > Workflow Administration > Application Types > Device Migration).


Typical roles include:

  • source device, representing the device being replaced

  • target device, representing the replacement device

  • neighbor device, representing adjacent devices affected by the migration

Roles determine which migration actions apply to each device. Assigning a role does not modify device configuration by itself.

Actions in a migration MOP reference devices through the labels assigned to them, such as source, target, or neighbor. These labels allow the same MOP structure to be reused across different devices or environments. During execution, device-specific details are resolved dynamically through these labels so that each action operates on the correct device.

Migration structure

A Device Migration job follows a predefined structural layout specified by its migration MOP. The MOP organizes the migration into a set of ordered stages, with each stage containing one or more migration MOP actions.


Attention


Device Migration is not shipped with a pre-built MOP. You must create your own MOP to perform specific tasks to facilitate the migration process.


Within this structure, the MOP determines:

  • the sequence in which migration stages are executed

  • the MOP actions associated with each stage

  • the order in which MOP actions are evaluated within a stage

This structural definition governs how the migration progresses from initial preparation through final completion. The MOP structure remains fixed for the duration of the migration job and is not modified during execution, ensuring predictable and repeatable behavior.


Important


Predefined stages are included in the Device Migration application type. You can add additional stages to support your migration scenarios. Predefined stages cannot be removed.


Migration stages

This topic describes the predefined stages available in Device Migration. These stages act as placeholders for grouping related migration actions. The stages themselves do not trigger any changes on the network; all operational changes occur through the actions you add within each stage.


Important


You can add new custom stages by editing the Device Migration application (Administration > Workflow Administration > Application Types > Device Migration).


Pre-provision

The Pre-provision stage is used to validate the existing network state before the migration starts. You add actions here to confirm that the network is stable and that all prerequisites for migration are satisfied.

Typical actions include checking the health of services on the source device, verifying expected traffic paths, and running reachability tests such as ping or traceroute. No routing or topology changes are performed in this stage.

Pre-migration

The Pre-migration stage where you add actions that prepare the target device before any traffic or routing changes occur. This stage is intended for bringing the target device into a ready state.

Typical actions you may add include creating a service instance for the target device, applying baseline configuration such as interfaces or routing parameters, and validating that the service instance deploys successfully. Failures at this point generally indicate configuration or service-definition issues and can be corrected without impacting live traffic.

Migration

The Migration stage where you place the actions that perform the actual transition of services and traffic from the source device to the target device. This stage contains the coordinated changes required to complete the migration.

Typical actions include diverting traffic away from the source device (often through neighbor devices), deploying the full configuration on the target device, and updating routing so that traffic moves to the new device. Validation steps confirm that traffic flows correctly after each change. Traffic remains active throughout this stage, and diversion actions ensure continuity.

Post-migration

The Post-migration stage contains the actions you add to finalize the migration after traffic has successfully moved to the target device. This stage ensures that the new state is stable and removes configuration that is no longer needed.

Typical actions include validating traffic on the target device, removing the service instance for the source device, and decommissioning the old device configuration.

Supported environments and constraints

Device Migration operates within the limits of the devices, vendors, and services supported by the system. All devices included in a migration must satisfy specific prerequisites to ensure successful execution.

Device requirements

All devices participating in a Device Migration job must:

  • Be present in the system inventory

  • Be reachable at the time of job execution

Devices that do not meet these criteria cannot participate in the migration.

Environment support

Device Migration supports heterogeneous environments. Devices involved in a migration do not need to be of the same model or vendor, provided they satisfy the requirements of the migration definition. This includes support for multi-vendor environments such as Cisco and Juniper.

MOP customization considerations

Device Migration does not include any pre-built MOPs.

To perform a migration, you must create a migration MOP that reflects your specific scenario. The actions, stages, and validations you include depend on your device models, service implementation, and operational requirements.

Because migration needs differ across deployments, each MOP must be created from scratch and structured according to the steps required in your environment. This includes choosing the appropriate stages, selecting the required actions, and defining the sequence of checks needed to safely transition traffic and configuration to the target device.

Execution notes

  • Device-specific details (such as device name, IP address, device type, OS version, etc.) are resolved dynamically at execution time based on the migration definition.

  • Migration logic relies on standardized role references established during job configuration, enabling reuse of MOP structures across different environments.