# Ericsson OSS / ENM change plan

Sample deliverable · SynapseTel Cloud
Source: https://synapsetel.com/en/delivery-standards#change-recovery

> Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

## Scope

Releases, interfaces, maintenance window, and change owner.

- **Environment / release / date:** _Complete for the agreed engagement_
- **Accountable owner:** _Complete for the agreed engagement_

## Prerequisites

- [ ] Record source and target releases, deployment type, node mix, supported upgrade path and vendor support entitlement. Name the change owner and maintenance window.

## Checklist

- [ ] Confirm prerequisites, backup integrity and access. List interface, alarm, configuration and performance checks with expected results and an acceptance owner.
- [ ] Define stop conditions, recovery steps and who can authorize them. Record test evidence, exceptions and operator handover before closing the change.
- [ ] Verify compatibility, access, and backups.
- [ ] Agree stop conditions and recovery decisions.

## Pre-flight verification

Record pass, fail or not applicable in the status column and attach the evidence reference for every row before the change window opens.

| Check | Method / role | Pass criteria | Stop condition | Status |
| --- | --- | --- | --- | --- |
| Source and target releases sit on a supported upgrade path | Change owner with the vendor compatibility matrix and support entitlement | Installed release, target release, deployment type and every node model are listed as supported for the path | Any node model, release or deployment type outside the documented path |  |
| Verified backup of the manager and its databases | Platform engineer, vendor backup procedure and a restore exercised in the agreed environment | Backup completed inside the agreed age and a restore from it has been exercised | Backup older than the agreed age or restore not exercised |  |
| FM northbound alarm delivery on representative nodes | NOC engineer, alarm raise and clear on a reference node | Raise and clear reach every northbound consumer with the expected fields | Any consumer misses an alarm or receives changed fields |  |
| CM read and write on representative nodes | OSS engineer, read-only query followed by an approved reversible write | Query returns the expected attributes, the write applies and the reversal restores the value | Query fails, times out or the reversal does not restore the value |  |
| PM file collection and northbound delivery | Performance engineer, collection across one full reporting period | Files for every monitored node arrive complete and on time | Missing, partial or late files for any monitored node |  |
| Accounts, roles, time sources and certificates for the window | Change owner, named operators sign in with the roles the plan requires | Accounts, roles, NTP and certificate validity confirmed for every system in scope | Any required account, role or certificate not valid for the whole window |  |

## Stop conditions

- A pre-flight row fails or its evidence reference is missing.
- Alarm delivery to any northbound consumer stops or changes format during the window.
- A step overruns its allotted time plus the time the recovery procedure needs.
- Vendor support or the recovery authority is not reachable when the plan requires them.

## Rollback triggers

- The manager does not return to service inside the agreed restoration time after the change.
- Configuration operations on representative nodes fail after the change.
- Historical alarm or performance data is missing after the change and cannot be recovered from the backup.
- The accountable owner withdraws approval on a stop condition the plan names.

## Acceptance

**Expected result / acceptance threshold**

> Illustrative expected result: Compatibility and interface checks recorded; change and recovery decisions approved by the named owner.

**Observed result / evidence reference**

_Complete for the agreed engagement_

**Exception / decision / follow-up owner**

_Complete for the agreed engagement_

## Sign-off

| Role | Name | Date |
| --- | --- | --- |
| Prepared by |  |  |
| Reviewed by |  |  |
| Approved by (accountable owner) |  |  |
| Operations handover accepted by |  |  |

## Reference disclaimer

Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

Technology names describe the environments we work in. They do not imply vendor partnership, certification or authorization. Vendor licenses and support entitlements remain yours; our engineering assistance does not replace them.

Support hours, emergency coverage and response, restoration and resolution targets are stated beside each engagement option and in your agreement. Read them there rather than in a general note.
