Updating Safely

Updates become frightening when they are rare. The way to make them safe is to make them ordinary.

Where to find it

Architect Panel → Integration & Connections:

• Deployments — how a version reaches an environment

Architect Panel → Activity:

• Error Log — the first place a problem appears

The sequence

1. Read what changed, particularly anything flagged as breaking.
2. Apply it somewhere that is not production.
3. Exercise the things your organisation actually depends on.
4. Check the error log there.
5. Apply to production at a time somebody is watching.
6. Check the error log again.

Test what you actually use

Not everything — that is why updates get deferred. Write down the ten things your organisation would notice immediately if they broke, and exercise those.

A short honest list, actually tested, beats an exhaustive plan nobody completes.

Give particular attention to your own code

Extensions, custom fields and anything bespoke are the most likely things to break, because the platform's own tests do not cover them. They are also the things nobody remembers exist.

Keep a list of your customisations and check each after an update.

Be able to go back

Before applying anything: know how to revert, and have a backup you have confirmed exists rather than assumed. The confidence to update comes from being able to undo it.

Schema changes are separate

Database changes are a deliberate step with their own rollback, not something that happens as part of a deployment. Plan them as their own exercise and do not assume an application rollback undoes them.

Update at a sensible time

When people are available to notice and fix a problem. Not at the end of a Friday, not before a holiday, and not immediately before something your organisation depends on.

Small and frequent beats large and rare

A quarterly update is a manageable change with a short list of differences. Two years of updates applied at once is a project with an unknowable failure surface, and the reason organisations end up stranded on old versions.

Check the error log the next morning

Some problems only appear under real use — a scheduled task overnight, a monthly process, an integration that runs at eight. A clean log an hour after updating is not the same as a clean log the next day.

Worked example

An organisation updates quarterly on a Tuesday morning, having tested a written list of twelve things in a non-production environment and checked its three extensions specifically. The error log is reviewed that afternoon and again the next morning, which twice caught a scheduled task failing overnight.

Recommendations

• Keep a short written list of what to test.
• Check your own customisations specifically.
• Confirm the backup before you start.
• Check the log the next morning, not just after.