# VMware platform baseline and change checklist

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

> 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

Installed releases, hardware, storage, networks, and workload owners.

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

## Prerequisites

- [ ] Inventory vCenter, ESXi, clusters, vSAN architecture, hardware and firmware, networks, backup systems and guest application owners. Record installed and target releases and vendor entitlement.

## Checklist

- [ ] Check release interoperability and hardware compatibility. Agree management, networking, storage and representative workload tests with expected results and named acceptance owners.
- [ ] Document stop conditions, authorized change and recovery procedures, and measured restore evidence. Record exceptions and operational handover before accepting the change.
- [ ] Check release and hardware compatibility.
- [ ] Validate workload checks, recovery evidence, and handover.

## 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 |
| --- | --- | --- | --- | --- |
| Inventory complete for hosts, clusters, storage, networks and guests | Virtualization engineer, read-only inventory export from vCenter and the backup system | Every host, cluster and VM has an owner, an installed release and a backup record | A host or VM without a named owner or a backup record |  |
| Release interoperability and hardware compatibility | Virtualization engineer, vendor interoperability and hardware compatibility lists for the target releases | Every host, controller, firmware level and vSAN node is listed for the target release | Any host, controller or firmware level not listed for the target |  |
| Snapshot age and change-tracking state | Virtualization engineer, snapshot and changed block tracking report | No snapshot older than the agreed age on workloads in scope and change tracking consistent | A long-lived snapshot on a workload in scope |  |
| Storage and vSAN health | Storage engineer, vSAN health and resynchronisation status | Health checks pass, no resynchronisation in progress and every object compliant with its policy | Resynchronisation in progress or objects out of policy compliance |  |
| Backup and restore evidence | Backup engineer, restore of a representative VM into an isolated network | Restore completes and the guest passes its checks within the agreed objectives | Restore fails or exceeds the agreed objectives |  |
| Workload acceptance tests defined | Application owner, representative checks with expected results | Each check has a named owner, an expected result and a recorded pass | A workload in scope without a named owner or a defined check |  |

## Stop conditions

- A pre-flight row fails or its evidence reference is missing.
- vSAN or storage health degrades during the window.
- A host or VM fails to return to the expected state inside the time the step allows.
- The application owner for a workload in scope is not reachable for acceptance.

## Rollback triggers

- A host does not rejoin the cluster or storage is unavailable past the restoration time.
- A representative workload fails its acceptance checks after the change.
- Guest data written after the change cannot be reconciled with the retained source.
- The accountable owner withdraws approval on a stop condition the plan names.

## Acceptance

**Expected result / acceptance threshold**

> Illustrative expected result: Release and compatibility findings recorded; platform and workload checks accepted; recovery evidence and operational ownership documented.

**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.