Over the years, I’ve encountered many companies that have maintained their business logic in stored procedures, but the practice of doing so has died out, for good reasons ill hilight below. However, many codebases have been around for 10+ years, and may still have large amounts of business logic in them.
If you’re still writing business logic in SQL Stored Procedures, it’s time to stop. If you still have code that stores business login in SQL Stored Procedures its time to refactor!
I’m not saying rewrite everything at once. That would be ridiculous. It’s a massive cost with no direct stakeholder value. What I am saying is this:
From this point forward, stop creating new business logic in stored procedures.
And when you must change one, refactor that logic out into testable, mockable, maintainable code.
This is not about doing everything at once!
Take inspiration from the Azure DevOps team. When they decided to eliminate their suite of brittle, long-running system tests, they didn’t try to replace them in a single sprint. It took them four years of consistent work, in three-week sprints, to fully remove and replace those tests with something better. One step at a time. That’s what change looks like.
Break the cycle of adding more mess to the mess. Every stored procedure you don’t write is a future bug you won’t have to debug in production. Every time you choose code over SQL for business logic, you’re reclaiming control of your system.
Let’s be clear: this isn’t an abstract architectural debate. The reasons stored procedures are a bad place for business logic are grounded in hard-learned lessons from real teams, real outages, and real maintenance headaches. If you’re serious about engineering excellence , you need to treat stored procedures as a legacy constraint, not a strategic tool.
Before you write the next line of business logic in a stored procedure, ask yourself: is this something I want to debug at 2am with no tests, no telemetry, and no rollback plan?
That’s the reality of stored procedures. They make every part of your engineering practice harder. Get the logic out. Put it where it belongs—alongside the rest of your tested, observable, maintainable code.
You don’t need permission to start this. You don’t need a project. You just need a commitment to modern engineering discipline:
This is a pay-as-you-go modernisation strategy. It lets you progressively reduce technical debt without halting delivery.
Every time you refactor, you:
No single change flips the system. But every change you make is a step away from the fragile procedural past and toward a sustainable engineering future.
This isn’t about dogma. It’s about discipline. Modern software development demands testability, traceability, observability, and scalability. Stored procedures give you none of that.
If you’re maintaining logic in stored procedures, you’re fighting your tooling, your pipeline, and your team. Stop doing that.
Start small. Move incrementally. Raise the bar.
Modern software is built in code, not SQL.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
Lean SA
Kongsberg Maritime
Xceptor - Process and Data Automation
Akaditi
Flowmaster (a Mentor Graphics Company)
Genus Breeding Ltd
Ericson
Lockheed Martin
Alignment Healthcare
Epic Games
Higher Education Statistics Agency
Brandes Investment Partners L.P.
Boeing
Teleplan
Capita Secure Information Solutions Ltd
Sage
Freadom
ALS Life Sciences
Washington Department of Transport
Nottingham County Council
Ghana Police Service
Department of Work and Pensions (UK)
Royal Air Force
New Hampshire Supreme Court
Akaditi
Graham & Brown
Philips
Boeing
Alignment Healthcare
ALS Life Sciences