Rolling Out SOP Software: The First 90 Days

• Agree the structure: categories, naming and the numbering scheme for IDs and versions.
• Set up roles and permissions for authors, reviewers, approvers, owners and readers.
• Connect single sign-on and user provisioning if your plan includes them.
• Write the SOP that governs your SOPs: how to request a change, who approves and how often each SOP is reviewed.

Move the SOPs that matter most first: the ones used most often, used by new people, or asked about in audits. Put each through the new review and approval route instead of copying it across unchanged; migration is a chance to catch steps that no longer match the work. Assign each migrated SOP to the people who follow it and collect their confirmations.

Migrate the remaining SOPs in batches by owner. As each SOP goes live in the new tool, replace the old copy with a link or remove it, so only one current version exists. Then check three things: SOPs without an owner, SOPs without a review date, and SOPs whose assigned readers have not confirmed.

• Old copies stay in shared drives, and people keep following them.
• Every SOP is imported without review, so old errors move into the new system.
• Owners are not named, so reviews never happen.
• The plan bought does not include the approval or version history features the process assumes. Check the plan before you design the process.

Three signs: people search the new tool first when they need a procedure, change requests arrive through the agreed route instead of as edits to old files, and the first scheduled reviews happen on time. If any of the three is missing after 90 days, find out why before you migrate more content.