a·gen·tic a·gil·i·ty

Stop Writing Business Logic in Stored Procedures

Explains why business logic should not be written in stored procedures, highlighting testability, maintainability, scalability, and strategies for gradual code refactoring.

Published on
5 minute read
Image
https://nkdagility.com/resources/utAzlIGxj7O

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.

Stored Procedures are the wrong place for Business Logic

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.

  1. They can’t be tested properly - You need a full database instance with seed data. You need to run a slow test harness. There’s no mocking, no fast feedback, no isolation. If it can’t be unit tested, it can’t be trusted. Long-running system tests do not tell you if the code works, only that the long-running system tests that you created work.
  2. They don’t participate in CI/CD - Stored procedures are almost always deployed manually or via fragile SQL scripts. While it can be automated by things like Redgate, it’s often still brittle, breaks reproducibility, and blocks automated pipelines.
  3. They aren’t version-controlled like real code - While you can have them under source control, they are “copied” into source control... either by Readgate or manually by a developer. Manual tasks are risky! Remember the Knight Capital Group!
  4. They tightly couple your logic to the database - That kills portability and locks you into a specific database engine. It also makes testing, debugging, and observability painful. There have been attempts in the past to create “Unit Tests” for stored procedures, but they have largely been abandoned in favour of just getting our logic out of that scenario.
  5. They don’t scale - Stored procedures run on the most expensive, least scalable part of your infrastructure: the database server. Business logic belongs in services that can scale out.
  6. They violate the separation of concerns - Your database should store and retrieve data. Your application should handle logic. Stored procedures blur that line and create a big ball of mud.
  7. They’re hard to reason about - No dependency injection. No composition. No mocking. No telemetry. No proper logging. Just deeply procedural code with limited tooling support. If you have to rely on a debugger to see if your code works, you are doing it wrong.

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.

The strategy: don’t rip, refactor

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.

The benefits are compounding.

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.

The outcome?

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.

Technical Mastery Engineering Practices Software Development Technical Excellence Technical Debt
Subscribe

Related Blog

Related videos

Connect with Martin Hinshelwood

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.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Lean SA Logo

Lean SA

Kongsberg Maritime Logo

Kongsberg Maritime

Xceptor - Process and Data Automation Logo

Xceptor - Process and Data Automation

Akaditi Logo

Akaditi

Flowmaster (a Mentor Graphics Company) Logo

Flowmaster (a Mentor Graphics Company)

Genus Breeding Ltd Logo

Genus Breeding Ltd

Ericson Logo

Ericson

Lockheed Martin Logo

Lockheed Martin

Alignment Healthcare Logo

Alignment Healthcare

Epic Games Logo

Epic Games

Higher Education Statistics Agency Logo

Higher Education Statistics Agency

Brandes Investment Partners L.P. Logo

Brandes Investment Partners L.P.

Boeing Logo

Boeing

Teleplan Logo

Teleplan

Capita Secure Information Solutions Ltd Logo

Capita Secure Information Solutions Ltd

Sage Logo

Sage

Freadom Logo

Freadom

ALS Life Sciences Logo

ALS Life Sciences

Washington Department of Transport Logo

Washington Department of Transport

Nottingham County Council Logo

Nottingham County Council

Ghana Police Service Logo

Ghana Police Service

Department of Work and Pensions (UK) Logo

Department of Work and Pensions (UK)

Royal Air Force Logo

Royal Air Force

New Hampshire Supreme Court Logo

New Hampshire Supreme Court

Akaditi Logo

Akaditi

Graham & Brown Logo

Graham & Brown

Philips Logo

Philips

Boeing Logo

Boeing

Alignment Healthcare Logo

Alignment Healthcare

ALS Life Sciences Logo

ALS Life Sciences