Operate

Make a safe production change

Prepare, apply, check, and if needed reverse an approved production change.

Your progress

Follow this journey

0 steps complete
0%

Progress is saved only in this browser.

Before you start

  1. Name the approved change and its owner.
  2. List the affected service groups, databases, storage, tenants, and product areas.
  3. Record the current product and database versions.
  4. Define the healthy result and the stop point.
  5. Define how to reverse the change.
  6. Choose a maintenance time and tell affected people.

Create a recovery point

Back up the Control, Workflow, and AI databases at one release checkpoint. Include the required document, model, knowledge, runtime, and log data.

Verify the checkpoint before the change. A list of backup file names is not proof that the data can be restored.

Apply one controlled change

  1. Remove affected servers from normal traffic when needed.
  2. Pause work only when the approved plan requires it.
  3. Apply database updates once with the approved migration account.
  4. Apply the intended service or setting change.
  5. Start services in the approved order.
  6. Do not add unrelated fixes during the change.
The System operations Servers view
Check that the server is online and reporting before it receives work. Earlier development interface, captured 22 August 2026. Follow the current text for RC1. Open the full image.

Check the healthy result

  1. Confirm Live and Ready for every affected service group.
  2. Confirm each expected server appears in System operations.
  3. Check that queues move and new work reaches a final state.
  4. Test sign in and one allowed access decision.
  5. Test one safe workflow, case, and knowledge action when affected.
  6. Check the logs and audit record for unexpected failures.

Stop or reverse when needed

Stop when an agreed check fails, a required store is unavailable, or data versions do not match. Do not keep sending traffic while the cause is unknown.

Use the approved reverse plan. If it requires a restore, use the matching full checkpoint and verify it on the recovered system.

Record the result

Record the version, change time, people involved, checks, result, issue IDs, and audit or request IDs. Keep secrets and customer information out of the change record.

Next step

Use Verify a backup and restore and Investigate a problem.

Check the RC1 path

Use the exact platform upgrade procedure. Keep the installed database provider fixed and preserve protected registration state.

Pūnaha Docs

Search the guides

Enter at least two characters.

    Product screen

    View the full screenshot