What is Out-of-Process Change?
Definition
Out-of-Process Changes usually happen for understandable reasons: an emergency fix during an incident, a quick adjustment nobody thought to formalize afterward, a legacy habit from before a formal change process existed. Whatever the reason, the effect is the same: the database's actual state moves away from what its ChangeLog says it should be, without any record of what happened or why. Detecting these changes matters more than preventing every single one, since emergencies will always happen occasionally. What matters is having a way to notice when they occur and pull them back into the formal record afterward, rather than letting them accumulate silently.
Why Out-of-Process Changes matter
Every Out-of-Process Change is a small gap between what a team believes is true about a database and what's actually true. One or two might be harmless. Accumulated over months across a team with production access, they become the underlying reason drift exists at all, and the reason a routine deployment sometimes fails against assumptions that quietly stopped being accurate a while ago. They also complicate audits, since an auditor asking for a complete change history won't find these anywhere in the standard record.
How Out-of-Process Changes are identified
Because these changes bypass the deployment pipeline by definition, they can't be caught by anything that only watches the pipeline itself. Identifying them requires comparing a database's actual state against its expected state directly, which is what Drift Detection does: any difference it finds that doesn't correspond to a ChangeSet in the ChangeLog history is, by definition, an Out-of-Process Change. The more frequently this comparison runs, the sooner such a change gets caught after it happens.
How Liquibase helps
Liquibase Secure's drift detection flags Out-of-Process Changes as soon as a scheduled or on-demand check runs, rather than waiting for them to cause a visible problem. Once identified, the change can be formalized, written up as a proper ChangeSet and merged into the ChangeLog after the fact, closing the gap between actual and expected state instead of leaving it open for the next deployment to trip over. Some organizations track a running count of Out-of-Process Changes found per month as a leading indicator of process health, since a rising count usually means access controls or emergency procedures need attention before drift becomes a bigger problem. Reviewing detected instances as a group periodically, rather than one at a time as they're found, can reveal a common underlying cause, such as one team routinely needing emergency access, worth addressing directly.
