Playbook

How to Roll Out a New System Without Your SOP Library Going Stale on Day One

Whether it is an HRIS, ERP, QMS, or CRM. The pattern is the same. Most rollouts skip half of it.

By Matthew Bixby · 7 min read

Whether it is an HRIS, ERP, QMS, or CRM. The pattern is the same.

The new system goes live. The old SOPs — built around the old system — go stale instantly. Some get rewritten. Some get retired. Most fall into a third category: still technically in force, no longer accurate, nobody updates them because nobody is sure if they should.

Six months in, the SOP library is a mix of “current and accurate,” “current but wrong,” and “retired but still in the system.” The audit finds it. The team scrambles.

Here is the playbook for not letting that happen. Eight steps.

1

Inventory the SOPs the new system touches

Direct touches and downstream. Most teams undercount by half.

Direct touches are obvious: if you are rolling out a new HRIS, you know the employee onboarding SOP touches it. Downstream touches are the ones that get missed: the payroll reconciliation SOP that relies on data from the old HRIS, the access-provisioning SOP that has a step referencing the old admin console, the offboarding SOP that has a workflow ID hard-coded in step 7.

Walk every SOP. Ask: does this document mention the old system, reference data from it, depend on a workflow inside it, or describe a process that touches it? If yes, it is in scope.

2

Decide which SOPs get rewritten, retired, or thin-updated

Three buckets. No fourth.

Rewrite — the underlying process is changing. The old SOP no longer describes what the team does. Thin update — the process is the same, but specific steps reference the old system. Retire — the SOP is no longer relevant. Mark it retired. Do not leave it in place "in case."

If you find yourself wanting a fourth bucket ("maybe rewrite, not sure yet"), the answer is rewrite. Indecision is rewrite.

3

Use AI to draft the rewrites

Pull the old version straight from Google Drive or wherever it lives. Define the new process flow — even a rough outline. Let AI produce the first cut.

This saves days. The first draft is 80–90% there. The remaining 10–20% is voice, accuracy, and the specific decisions only the team can make. Humans confirm.

The mistake is treating the AI draft as the finished product. It is not. It is a starting point that compresses the blank-page phase from days to minutes.

4

Map each rewritten SOP to the underlying controls

SOC 2, ISO, HIPAA, internal. AI handles the first pass. You confirm.

Why now: if you wait until after the rollout to map, you are doing the work twice. Map at the moment of rewrite. The control alignment is freshest in everyone's heads. You will catch coverage gaps before the audit does.

5

Assign one named owner per SOP

The owner is on the hook for the next review. Not a team. Not a queue. A person.

Distributed ownership is the same as no ownership. If your org chart resists naming individuals, push back. Collective ownership of a document is a recipe for nobody reviewing it.

6

Set the review trigger before go-live

Calendar-based. Real date. Real owner gets the alert.

The trigger should fire 30 days before the review is due, not the day it is due. Reviews take time. Owners are busy. The alert needs lead time.

Do not skip this step on the theory that "we will figure out reviews after launch." You will not.

7

Require acknowledgment at effective date

Not in a sweep three months later.

When the new SOP goes live, the people responsible for following it acknowledge it that day. The acknowledgment is tied to the specific version. New version, new acknowledgment.

Why this matters: acknowledgment captured at effective date is a real behavior signal. Acknowledgment collected three months later in a sweep is paperwork. Auditors can usually tell the difference.

8

Run one full cycle on one SOP end-to-end before the rollout

Pick one SOP. Walk it through the entire flow: draft → review → approve → publish → acknowledge → exportable evidence. End-to-end. Before the system goes live.

This is the rehearsal. It is also where you find the bugs in the workflow you designed. You will find something. You always do. Better to find it now than during audit week.

The summary

Most rollouts skip half of these steps. Then the audit finds it. Then the team rebuilds.

The cleanest rollouts I have run finish with the audit story already written, not waiting in line behind the implementation. That is not luck. That is the eight steps above, in that order, done deliberately.

Matthew Bixby is co-founder of SOP Studio and a principal at McBix Consultants.