Govern What Changes: What Actually Breaks a Well-Run GP Shop
The fourth decision every staying shop faces — and the one that determines whether the first three actually hold.
A well-run GP environment rarely gets wrecked by neglect. It gets wrecked by a change. Someone moves SQL Server to a new version, or rehosts to a new operating system, or applies a GP update — a sensible, necessary move, exactly the kind this series has been arguing for — and something breaks. And the thing that breaks is almost never GP itself. It’s a dependency sitting on top of it: an ISV add-on that wasn’t certified on the new SQL version, an integration that assumed the old server name, or a customization nobody remembered was still there.
That pattern points at the real governance question for a staying shop. It was never “how do we avoid change” — you can’t, not for years — it’s “how do we make change something we survive on purpose, instead of something that catches us.” Two separate disciplines answer that, and they turn out to be the same discipline wearing two faces: Govern what you deliberately change and govern what an attacker could change without your permission.
Confirm Before You Move, Not After Something Breaks
The fix for the first kind of change is simple to state and easy to skip: Before you move any platform layer, confirm every add-on, integration, and customization is supported on the target — first, not after, and not “we’ll deal with it if something breaks.”
That confirmation must be in writing, not assumed. A vendor’s actual statement that its product is certified on the SQL Server version, Windows Server version, or GP build you’re moving to is a pass; “it’ll probably be fine” is not.
Where a vendor can’t or won’t confirm — gone quiet, orphaned product, nobody willing to commit — you don’t get to skip the check. You become the check: stand the change up in a non-production copy and prove the dependency works there before it touches anything real. The rule that makes this work is that an unconfirmed, untested dependency holds the change. Not “proceed carefully.” Holds. A gate you walk through anyway when it’s red isn’t a gate.
The other half of surviving a change on purpose is deciding, before you start, exactly what makes you stop. Every change has a point after which backing out stops being a simple reversal and becomes a full restoration from your last verified backup — and every change should have a named trigger, agreed in advance, for when you pull that cord. Deciding both of those things in the calm of a planning meeting is a different exercise from deciding them at one in the morning with a batch stuck halfway and the business waiting. Write them down first.
The Record You Build is the Evidence an Auditor Already Wants
Here’s what makes doing this properly worth more than the risk it prevents: The record a disciplined change process produces — what changed, who approved it, what was tested, what the rollback plan was, what got validated afterward — is close to exactly what a financial-statement auditor asks to see when a system holding your general ledger gets touched. Change management is one of the standard controls that auditors test and GP, sitting under your GL and subledgers, is squarely in scope.
While GP was under active vendor support, some of that assurance came from Microsoft — a patch that had gone through the vendor’s own testing before it reached you. Running GP on your own terms past 2029 doesn’t create a new obligation; it removes the part of the answer that used to be someone else’s to supply.
Your own documented discipline becomes the whole control, not half of it. The distance between “we upgraded SQL last spring, I think it went fine” and a dated, signed record with evidence attached is the distance between an audit finding and a clean pass. And it costs nothing extra to produce, if the discipline above was already followed. It’s the same work, written down as you go rather than reconstructed under pressure months later.
Controlling What Can Reach You Matters More Than What’s Been Patched
The second face of this same discipline shows up in a conversation almost every staying shop eventually has, usually framed as a dead end: After April 30, 2031, GP stops receiving security patches entirely. When said that way, it sounds like the end of the argument for staying. It isn’t, and the reason is worth sitting with, because it reframes the whole security question.
An unpatched flaw and an actual risk are not the same thing. An unpatched application sitting exposed on the open internet is a genuine emergency. That same unpatched application, on a network segment nothing outside it can reach, running services scoped to exactly what they need and nothing more, is a manageable situation. This is because the flaw has no path to anyone who’d exploit it.
The difference between those two isn’t the patch. It’s the environment, and the environment is something you control entirely on your own, without waiting on a vendor.
That’s also where the platform-currency habit from earlier in this series pays a second dividend. GP being frozen doesn’t mean everything under it is frozen — Windows Server and SQL Server keep their own support clocks, and most of the actual attack surface in a GP environment lives in that platform layer rather than in the application itself. Keeping that layer current and patched, for as long as it remains patchable, does more for your security posture past 2031 than anything specific to GP could.
The discipline underneath both halves of this is the same one: Control what’s reachable, control what a reached account can do, and keep a clean way back if a control ever fails anyway. None of it depends on a vendor shipping one more fix. All of it depends on you — which is exactly the posture this whole series has been arguing a staying shop can hold.
The Bottom Line
Every article in this series, so far, has been about knowing where you stand — your license, your platform’s clocks, your ability to actually recover. This one is about the moment all of that gets tested: the moment something changes, whether you initiated it or an attacker did.
A staying shop doesn’t win by freezing everything in place and hoping nothing moves. It wins by making change something it does on purpose — dependencies confirmed before anything gets touched, a way back decided before anything starts, and a perimeter tight enough that an unpatched flaw has nowhere left to travel.
That’s not a heavier burden than running GP under active support used to be. It’s the same burden, made visible, now that there’s no vendor left to quietly carry half of it for you.
