---
alias: tutorials-automation-scheduled-action-scenario-01-change-automation-manager
description: "Show how to move Automation Controller Instances between Automation Managers by using a readiness-driven Automation Scheduled Action definition."
---

# Scenario 1 - Change Automation Manager

## Overview

This scenario shows how to use the **Change Automation Manager** action to move **Automation Controller Instances** from one **Automation Manager** to another without interrupting production. The definition waits until each instance enters a safe, stable state before performing the move, allowing infrastructure changes without a forced shutdown.

In this example, three cookie factory mixing-line instances move from the `mixing-manager-legacy` **Automation Manager** to `mixing-manager-nextgen` during a year-end holiday shutdown. This operation runs in parallel with [Scenario 2](02-holiday-shutdown-molding-controller.md), which handles the molding controller update during the same window.

### When to Use

- **Host maintenance** - OS patching, hardware replacement, or software upgrades on the **Manager** host that require the service to stop.
- **Decommission** - retiring an older **Manager** host and consolidating all its instances onto a replacement.
- **Load rebalancing** - redistributing instances across **Managers** when one host is over-utilized or when new capacity is added to the fleet.
- **Network topology change** - moving instances to a **Manager** running in a different network segment or closer to the equipment after an infrastructure reorganization.
- **Disaster recovery** - evacuating instances from a degraded or at-risk **Manager** to a healthy standby before a failure forces an unplanned outage.

### Example

This is the first operation in the year-end platform refresh. On 28 December, the holiday shutdown begins and infrastructure consolidation starts: all three mixing-line instances currently running on `mixing-manager-legacy` must move to `mixing-manager-nextgen` before production resumes. The legacy host is being decommissioned. The other holiday operation, the molding controller update, runs in parallel on separate **Resources**; see [Scenario 2](02-holiday-shutdown-molding-controller.md).

The factory is consolidating its mixing infrastructure. The older host running `mixing-automation-manager-legacy` is being decommissioned; all instances must move to the newer, higher-capacity host running `mixing-manager-nextgen`. The factory has the following context:

- **Resources**: 3 mixers (`ASA Mixer-01`, `ASA Mixer-02`, `ASA Mixer-03`).
- One **Automation Controller** associated with all **Resources**: `MixingController [A.1]`.
- Source **Automation Manager**: `mixing-manager-legacy` (being decommissioned).
- Target **Automation Manager**: `mixing-manager-nextgen` (replacement host).

```mermaid
graph LR
    subgraph legacy["mixing-manager-legacy (source)"]
        M1[Mixer-01]
        M2[Mixer-02]
        M3[Mixer-03]
    end
    subgraph nextgen["mixing-manager-nextgen (target)"]
        M1T[Mixer-01]
        M2T[Mixer-02]
        M3T[Mixer-03]
    end
    M1 -->|migrate| M1T
    M2 -->|migrate| M2T
    M3 -->|migrate| M3T
```

## Prerequisites

Before creating the Definition, confirm the following:

- Load the Scenario 1 Automation master data into MES. It creates the `MixingController [A.1]` Controller, `mixing-manager-legacy` and `mixing-manager-nextgen` **Manager** records, and all three mixing instances (master data package: [01-automation-masterdata.json](./masterdata/scenario01/01-automation-masterdata.json)).
- `mixing-manager-legacy` host is running and the three mixing instances are active and connected.
- `mixing-manager-nextgen` host is running, reachable, and has sufficient capacity for the migrated instances.
- Each **Automation Controller Instance** is linked to a **Resource** with a valid state model that includes states such as `Standby` or `Scheduled Down`.
- MES Configuration Entry `/Cmf/Tutorials/AutomationScheduleAction/Scenario1/NumberOfAvailableSlots` exists and is set to the number of migrations you want to allow in this run. Use `3` if you want all three sample instances to pass the capacity gate.
- Notification templates `ASA PreAction Template`, `ASA Success Template`, `ASA Failure Template`, and `ASA Ignored Template` exist in MES if you intend to use notifications.
- **DEE action** [`ASA_Scenario1_CheckNextgenManagerHasCapacity`](./dees/ASA_Scenario1_CheckNextgenManagerHasCapacity.cs) is created and deployed in MES before enabling the Definition (see [[howto-iot-import-dee-action]]).

## Configuration

### Why This Pattern

This Definition uses the following combination of components:

| Component | Type | Purpose |
|---|---|---|
| **Context** | `AutomationManager` | Resolves all instances currently hosted by `mixing-manager-legacy`. |
| **Pre-Conditions** | `AllowedWeekdays` + `AllowedTimeWindow` | Restricts processing to the planned maintenance window. |
| **Detector** | `EntityStateInList` | Prevents migration while the **Resource** is in a productive or unknown state. |
| **Acceptance Gates** | `ReadyDelay` + `CustomDeeAction` | Two **Acceptance Gates** evaluated in order: first confirms the **Resource** has held the ready state for a minimum period; second verifies the target **Manager** has enough capacity before the migration proceeds. Both must pass. |
| **Action** | `ChangeAutomationManager` | Moves the instance hosting to `mixing-manager-nextgen`. |
| **Post Action Validation** | `MaxStartupTime` | Confirms the migrated instance returns to a running state within the configured timeout. |

Table 1: Scenario 1 Component Design

### Create the Definition

Open **Automation Scheduled Action** and select **Create**.

Refer to [[user-guide-automation-scheduled-action-create|Create Definition]] for more information.

#### Tab 1 - General Data

Start by filling in the general definition fields.

- Give it a name like `CF_Migrate_Legacy_To_Nextgen` and a description that explains its purpose (for example, "Move cookie line instances from mixing-manager-legacy to mixing-manager-nextgen when lines are stable and ready.")
- Set **Is Enabled** to `Disabled` for now; you'll enable it after verifying the task list.
- Set **Validity** to `2` days.

For **Context**, select **Automation Manager** and enter `mixing-manager-legacy` as the target **Manager**. All instances currently hosted by this **Manager** become targets. One task is created per instance.

For the **Detector**, select **Entity State In List** and add `Scheduled Down` to the state list. Adjust the state list to match your factory's state model.

For the **Action**, select **Change Automation Manager** and set the target to `mixing-manager-nextgen`.

Optionally, configure notification templates to be alerted at key moments:

| Field | Template |
|---|---|
| Pre-Action | `ASA PreAction Template` |
| Success | `ASA Success Template` |
| Failure | `ASA Failure Template` |
| Ignored | `ASA Ignored Template` |

Table 2: Scenario 1 Notification Templates

#### Tab 2 - Pre-Conditions

Select :material-plus: twice to add the following **Pre-Conditions** in this order:

**1. Allowed Weekdays** - Set the weekdays to `Saturday` and `Sunday`.

**2. Allowed Time Window** - Set the window to `00:00–06:00`.

!!! warning "All times are evaluated in UTC"
    Adjust both Pre-Conditions to match your planned maintenance window. If your plant operates in a different timezone, convert the window to UTC before entering it here.

#### Tab 3 - Acceptance Gates

Select :material-plus: twice to add the following **Acceptance Gates** in this order:

**1. Ready Delay** - Set the delay to `300` seconds. The line must hold the ready state for 5 minutes before the migration runs. This prevents acting on brief state transitions during a normal production pause.

**2. DEE Action** - Enter `ASA_Scenario1_CheckNextgenManagerHasCapacity` as the action. This verifies that `mixing-manager-nextgen` has enough capacity before the migration proceeds. If the action returns `false`, the task stays at `SkippedGateFailed` until capacity is available.

#### Tab 4 - Post-Action Validations

Select :material-plus: and select **Max Startup Time**. Set the timeout to `300` seconds. This confirms the migrated instance returns to a running state within 5 minutes on the new **Manager**.

!!! tip "Verify tasks before enabling"
    Select **Save** with `Is Enabled` set to `Disabled`. The system immediately resolves the context and creates one task per target instance.

    Before enabling, open Automation Scheduled Action Tasks and confirm:

    - All expected targets appear in the task list.
    - No unexpected targets are included.

    Once the task list is correct, enable the Definition from the top ribbon (see [[user-guide-automation-scheduled-action-enable-disable|Enable / Disable Definition]]).

## How It Works at Runtime

After you enable the Definition, the system processes each task on every polling pass as follows:

1. **Context** resolves all instances currently hosted by `mixing-manager-legacy` and creates one task per instance.
2. Weekday and time-window **Pre-Conditions** are checked against current UTC time. Tasks are skipped outside the allowed window.
3. The **Detector** checks whether the linked entity state is `Standby` or `Scheduled Down`.
4. The `ReadyDelay` **Acceptance Gate** confirms the line has remained in that state for at least 5 minutes.
5. `ASA_Scenario1_CheckNextgenManagerHasCapacity` confirms `mixing-manager-nextgen` has sufficient capacity to accept the instance. If it returns `false`, the task is skipped with `SkippedGateFailed` and retried on the next pass.
6. The **Action** moves the instance to `mixing-manager-nextgen`.
7. **Post-Action Validation** waits up to 5 minutes for the instance to reach a running state on the new **Manager**.
8. The task is finalized with outcome and notifications are sent.

```mermaid
flowchart TD
    A([Task per instance]) --> B{"Weekend?<br/>00:00-06:00 UTC?"}
    B -- No --> S1([SkippedPreConditionFailed])
    B -- Yes --> C{"Line state =<br/>Standby or<br/>Scheduled Down?"}
    C -- No --> S2([SkippedNotReady])
    C -- Yes --> D{"Stable 5+ min?"}
    D -- No --> S3([SkippedGateFailed])
    D -- Yes --> G{"nextgen manager<br/>has capacity?"}
    G -- No --> S3
    G -- Yes --> E[ChangeAutomationManager]
    E --> NOP{"Already on<br/>mixing-manager-nextgen?"}
    NOP -- Yes --> IGN([IgnoredNoOp])
    NOP -- No --> F{"Running within<br/>300 s?"}
    F -- No --> FAIL([ValidationFailed])
    F -- Yes --> OK([ProcessedSuccess])
```

## Expected Task Outcomes

| `LastOutcome` | `State` | Meaning |
|---|---|---|
| `ProcessedSuccess` | `Processed` | Migration succeeded and the instance started correctly on `mixing-manager-nextgen`. |
| `IgnoredNoOp` | `Ignored` | Instance was already hosted by `mixing-manager-nextgen` - no change needed. |
| `ActionFailed` | `Failed` | **Manager** migration failed. Check infrastructure capacity and **Automation Manager** reachability. |
| `ValidationFailed` | `Failed` | Migration ran but the instance did not reach running state within 300 seconds. |
| `SkippedPreConditionFailed` | (task stays active) | Current UTC time or weekday is outside the allowed window. |
| `SkippedNotReady` | (task stays active) | Line state is not in the ready list. |
| `SkippedGateFailed` | (task stays active) | Line became ready but has not sustained that state for 5 minutes yet, or the nextgen manager capacity check returned `false`. |

Table 3: Scenario 1 Task Outcomes

## Simulating This Scenario

Confirm that all three instances (`ASA Mixer-01`, `ASA Mixer-02`, `ASA Mixer-03`) are running and communicating on `mixing-manager-legacy`, and that `mixing-manager-nextgen` is running and has capacity.

This scenario uses `EntityStateInList` as the **Detector**. Readiness is controlled by changing the **Resource** state and no file operations are needed.

### To Trigger Processing for One Line

1. Navigate to the **Resource**, for example `ASA Mixer-01`.
2. Transition its state to `Scheduled Down`.
3. Open **Automation Scheduled Action** Task and confirm `IsReady` becomes `true` for that task.
4. Wait 5 minutes. The `ReadyDelay` **Acceptance Gate** passes, then `ASA_Scenario1_CheckNextgenManagerHasCapacity` is evaluated. Capacity is read from the MES configuration value `/Cmf/Tutorials/AutomationScheduleAction/Scenario1/NumberOfAvailableSlots`. If the value is greater than `0`, the **Acceptance Gate** passes, the slot is reserved (value decremented by 1), and the task executes `ChangeAutomationManager`. Set it to `0` to simulate a full target **Manager**.
5. Confirm the instance is now hosted by `mixing-manager-nextgen` in the **Automation Controller Instance** record.
6. The task transitions to `ProcessedSuccess`.

Repeat steps 1–6 for the remaining **Resources** (`ASA Mixer-02`, `ASA Mixer-03`). Each **Resource** is processed independently as it reaches and sustains the ready state.

### To Observe the Gate Countdown

Open the task and watch `ReadyStateChangedAt`. The **Acceptance Gate** requires this timestamp to be at least 5 minutes in the past before the action runs. If the line leaves the ready state before the **Acceptance Gate** passes, `ReadyStateChangedAt` resets and the countdown starts over.

### To Observe the Ignored Outcome

Before enabling the Definition, manually move one instance to `mixing-manager-nextgen` directly from the **Automation Controller Instance** record. Enable the Definition and the task for that instance transitions immediately to `IgnoredNoOp` because the target is already in the desired state.

### To Reset and Repeat

1. Transition the **Resource** state back to `Running`.
2. In the **Automation Controller Instance**, move the instance back to `mixing-manager-legacy`.
3. Create a new Definition (the original tasks are in a terminal state and will not re-evaluate).

## Troubleshooting

### Lines Without a State Model

`EntityStateInList` requires a valid MES state model on the linked **Resource**. If a line has no state model, the **Detector** fails closed and the task is permanently skipped.

Use `DefinedInWorkflow` or `CustomDeeAction` as the **Detector** instead when a state model is not available.

### Inconsistent Target Mapping

Every **Automation Controller Instance** must map cleanly to a single **Resource**. If the mapping is inconsistent, task creation fails for that target. Verify **Resource** assignments in the **Automation Controller Instance** before enabling the Definition.

### Piloting the Migration

Before pointing the **Context Resolution** at the full **Automation Manager**, test with a single instance by using `Context = AutomationController` targeting one **Automation Controller**. Confirm the outcome is `Processed`, then switch to `Context = AutomationManager` to process the rest.