What is the difference between defect severity and priority?

Severity is how bad the defect is if it happens — its impact on the business or the numbers. Priority is how soon it must be fixed relative to everything else. They're independent: a cosmetic label error on a screen thousands of people see might be low severity but high priority; a wrong calculation in an obscure edge case might be high severity but lower priority if it rarely occurs before a later fix. Triage sets both, deliberately, because conflating them is how teams either fix trivia urgently or defer something that should have blocked go-live. Severity describes the defect; priority describes the plan.

What counts as a go-live blocker?

A blocker is a defect that makes go-live unacceptable regardless of how much else works — typically anything that produces a wrong financial number with no workaround, breaks a critical process end-to-end (a payment can't be made, a statement can't be posted), or creates a control or compliance failure. The test is not 'is it annoying' but 'can the business operate correctly and safely with this live?' Blockers are defined in advance, agreed with the business owner, and they gate the decision absolutely: an open blocker means no-go, however good the rest of the picture looks.

What are exit criteria for testing and go-live?

Exit criteria are the agreed conditions that must be true to declare a test phase complete or to proceed to go-live — set before testing starts, not negotiated under pressure at the end. They typically cover: no open blockers or critical defects; every remaining open defect has an owner, an assessed impact and either a fix plan or an explicitly accepted workaround; critical business processes have passed end-to-end; and the business owner has signed off. Good exit criteria turn go/no-go from an argument about optimism into a check against evidence.

Defect Triage & Exit Criteria for Finance Go-Lives

Every finance go-live comes down to one honest question asked under pressure: are the defects that are still open acceptable to run the business on? By the final week, the backlog is never empty — real projects go live with known defects. What separates a controlled go-live from a gamble is whether those defects were triaged (understood, classified, owned) and whether the decision to proceed was made against exit criteria agreed in advance, rather than against fatigue and hope. This is how to run both — so the go/no-go is a check against evidence, not a vote on optimism.

Severity and priority are two different questions

The most common triage mistake is treating "how bad" and "how soon" as one dial. They're independent axes, and keeping them separate is what stops teams fixing trivia urgently while deferring something that should have blocked go-live.

Severity = impact if it occurs. Does it produce a wrong number? Break a process? Fail a control?
Priority = how soon it must be fixed, relative to everything else competing for the same days.

A cosmetic error on a high-traffic screen: low severity, high priority (it's embarrassing and everyone sees it). A wrong calculation in a rare edge case: high severity, lower priority (fix it, but maybe not before an event that can't occur for weeks). Triage sets both, on purpose.

Severity ↓ / Priority →	Fix now	Fix before go-live	Fix after go-live
Critical (wrong number / broken process / control fail)	Blocker — stop and fix	Blocker — gates go-live	Only with an accepted workaround
Major (significant but contained)	If quick and safe	Usually yes	With owner + plan
Minor (cosmetic / rare / easily worked around)	Rarely	If cheap	Default home

The grid isn't the point — the conversation it forces is. Every open defect gets placed on it deliberately, with the business in the room, so nothing drifts into go-live unexamined.

Blockers: defined in advance, non-negotiable at the end

A blocker is a defect that makes go-live unacceptable no matter what else works. Define the category before testing, agreed with the business owner, so it can't be argued away at 11pm on cutover eve. The reliable tests:

It produces a wrong financial number with no workaround.
It breaks a critical process end-to-end — a payment can't be made, a bank statement can't be posted, a period can't close.
It causes a control or compliance failure.

The question a blocker answers is never "is this annoying?" It's "can the business operate correctly and safely with this live?" If the answer is no, it's a blocker — and one open blocker is a no-go, however green everything else looks.

This is exactly the hard gate in the cutover go/no-go decision: blockers gate absolutely, and a passed gate still isn't a "go" until someone with authority decides. The go-live readiness checklist makes that separation concrete.

Accepted defects and workarounds: the honest middle

Real go-lives carry open defects across the line — and that's fine, if it's done honestly. An accepted defect is one the business has consciously agreed to live with, for now, with three things attached:

An assessed impact — what it does, how often, to whom. Not "minor," but a real description.
A workaround — the manual or interim step that makes it survivable — tested, not assumed, and owned by someone who'll actually do it.
A fix plan and owner — when it gets resolved and who's accountable, so "accepted" doesn't quietly become "forgotten."

The failure mode isn't going live with open defects — it's going live with defects nobody decided to accept. A defect you chose to carry, with eyes open and a workaround in hand, is managed risk. The same defect discovered live, with no plan, is an incident.

Exit criteria: agree them before you need them

Exit criteria are the conditions that must be true to complete a test phase or proceed to go-live — and their power comes entirely from being set in advance. Agreed at the end, under pressure, they're just a renegotiation of optimism. A workable set:

No open blockers or critical defects. (The absolute gate.)
Every remaining open defect has an owner, an assessed impact, and either a fix plan or an explicitly accepted workaround.
Critical business processes have passed end-to-end — not component checks, real scenarios (the point of proper UAT).
Defect trend is under control — the open count is falling and inflow has slowed, not a backlog still growing.
The business owner has signed off against this evidence.

Watch two signals that a project is drifting toward a bad go-live even when the headline numbers look fine:

Defect ageing. Old open defects that never move are usually the hard ones being avoided — the backlog's true risk hides in its oldest entries, not its newest.
Reclassification pressure. Blockers quietly downgraded to "major" as the date approaches. When severity starts falling without the defect changing, the deadline is driving the triage — exactly backwards.

What good looks like

Severity and priority set separately on every defect, with the business, against a shared grid.
Blockers defined up front and treated as an absolute gate — no end-of-project reclassification.
Open defects are decided, not just present — each with impact, a tested workaround, and an owner.
Exit criteria agreed before testing starts, so go/no-go is a check against evidence.
Ageing and reclassification watched as the early-warning signals they are.

Do this and go-live becomes a defensible decision you can put your name to: here's what's open, here's why it's acceptable, here's who owns what's left. Skip it and the decision gets made anyway — by the calendar, on the night, with the hardest defects quietly reclassified so the date can hold. Triage and exit criteria are how you make the honest call instead of the convenient one. Running intake and defect decisions across a programme is exactly the kind of queue Delivery Sheet is built to keep straight.

Part of the Finance Systems Delivery guide. See also user acceptance testing for finance systems and cutover & go-live for finance systems. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.