# Standard Operating Procedure: Plugin & Core Update Process

- Link: https://ip.ipdev2.cloud/standard-operating-procedure-plugin-core-update-process/
- Published: 2026-05-11T09:53:00+00:00
- Author: neilharner

## Overview & Purpose

This document outlines the standardized workflow for managing plugin, theme, and
WordPress core updates. The primary objective is to ensure site stability, security,
and high performance while minimizing disruption to users during peak certification
periods.

## Scheduling & Cadence

 * **Deployment Window:** Updates must be deployed during the **beginning or middle
   of the month**.
 * **Blackout Dates:** These are specific per the client based on their customers
   and business needs.
 * **Bi-Annual Reconciliation:** Twice per year, all development and PMA environments
   must be fully synced with Production. This maintenance cycle must include a comprehensive
   purge of error logs across all instances.

## Execution Workflow

### Phase I: Preparation & Audit (WEEK 1)

**Step 1: Environment Readiness:** Verify with the Inverse Paradox (IP) internal
team that no active development is occurring on the PMA environments. At the end
of the PMA, the deploy should be a clean merge from the PMA branch to the Production
branch, therefore only PMA-related development activities should take place in this
environment. _Action: If active work is detected, notify the Project Manager to 
pause development or adjust the environment set-up before proceeding._

**Step 2: Version Auditing**

 * **Comparison:** Cross-reference website plugins against developer changelogs 
   to identify the most recent stable versions. The WordPress updates will include
   update versions for plugins available from the WordPress.org Plugin Repository,
   but **_all_** commercially available plugins will require verification of the
   latest version from the vendor website. Based on the comparison of this list,
   these are the plugins that will be updated.
 * **Documentation:** Depending on the scope of the PMA and site, all proposed updates,
   additions, or removals will be recorded in a PMA report.

---

### Phase II: Development & Testing (WEEK 2)

**Step 3: Implementation:** Execute updates on the PMA environment for the following:

 * Update plugins to the latest version available.
    - Plugins available from the WordPress.org plugin repository can be updated 
      via automatic pull requests from inside the WordPress Dashboard.
    - Commercial plugins will need to be updated manually _one at a time_.
 * Verify WordPress core is at the latest possible version.
 * Update any backup themes in the repository to the latest versions.
 * Check PHP Version and update to the recommended version.

**Step 4: Internal Quality Assurance (QA)**

 * When all updates are completed on the PMA environment, IP will conduct a comprehensive
   functional audit. Client specific “Critical Path” items will be tested.
 * _Remediation:_ All issues must have tasks created and assigned in the ClickUp
   PMA board under the _QA Issue Remediation _task. All issues must be resolved 
   before moving to Phase III.

---

### Phase III: Client Review & Approval (WEEK 3)

**Step 5: Client Notification & Feedback:** When QA is complete and all issues have
been resolved, notice will be sent to the client via ClickUp.

 * **Deliverables:** IP provides the finalized list of updated components.
 * **Review Cycle:** Client performs independent QA. Any discovered bugs are logged
   in ClickUp for IP remediation under the _QA Issue Remediation _task. This cycle
   repeats until all QA items pass and all remediation tasks are completed.

**Step 6: Formal Approval:** Client provides official written approval for deployment.
Both parties will then coordinate a specific deployment date and time.

---

### Phase IV: Deployment & Post-Launch (WEEK 4)

**Step 7: Production Deployment:** On the scheduled date, all approved updates (
Plugins, Core, Theme, and Remediation Code) are pushed to the live Production environment.

**Step 8: Post-Deployment QA:** IP immediately performs a second round of “Critical
Path” testing (identical to Step 4) on the live site.

 * _Action:_ Any post-launch regressions must have tasks created and assigned in
   ClickUp under a post-launch issue block for immediate priority remediation. Once
   remediation is completed for _all _QA issues, proceed to the final step.

**Step 9: Final Sign-off:** Once post-deployment remediation is complete, IP notifies
the client via ClickUp. Following a final verification by the client, the update
cycle is officially closed. If the client finds any further issues, they are sent
to clickup for resolution.