We Replaced Salesforce — Case Study | Heavy Chain Engineering

There’s a moment in every Salesforce org’s life where someone asks a simple question and nobody can answer it.

For us, it was: “Why does this vendor show as non-compliant when their insurance is current?”

The answer involved a formula field, two Flows (one marked obsolete but still deployed), an Apex batch job that ran nightly, and a race condition between them. Six components across three layers of Salesforce automation, and not a single person on the team could trace the full evaluation chain. The compliance status was wrong, and fixing it meant touching code that nobody had written tests for, in a system where every change risked breaking something else.

That was the moment we knew we weren’t going to fix Salesforce. We were going to replace it.

What Salesforce Was Actually Doing

Let me be specific about what we were dealing with. This wasn’t a CRM. Nobody was managing a sales pipeline or forecasting revenue. This was an operational system — vendor management, compliance tracking, insurance verification, onboarding workflows — all running on a platform designed to track leads and close deals.

The numbers: 1.5 million records across 51 custom objects. 9,500 vendor accounts. 608 active business logic components — 37 Flows, 15 Triggers, 387 Apex classes, 132 Lightning Web Components, 33 batch jobs, and 90+ formula fields. The largest Apex class was 4,096 lines.

And the real kicker: only 12 of those 37 Flows were actually active. The other 25 were marked obsolete but still deployed, like landmines in the codebase that nobody dared to remove.

The Account object was doing triple duty. Client accounts, vendor accounts, insurance brokers — all living in the same table, differentiated by a RecordType field. Every piece of business logic had to check “what kind of account is this?” before doing anything. CRM features like Opportunities bled across domains that had nothing to do with sales.

We were paying north of $200K/year in licensing for a tool that had become the most expensive spreadsheet in the building.

Why We Didn’t Stay

The conventional wisdom is to fix what you have. Hire a better Salesforce admin. Refactor the Flows. Clean up the Apex. We considered it.

But the problem wasn’t implementation quality. The problem was that Salesforce’s data model didn’t match our business domain. You can’t fix Account polymorphism with better Flows. You can’t make compliance logic deterministic when it’s scattered across formula fields, batch jobs, and triggers that fire in unpredictable order. And you definitely can’t give vendors a decent portal experience when Experience Cloud costs more per seat than the operational value of having them self-serve.

The cost of staying wasn’t just the license fees. It was the three-month estimate every time someone asked for a new feature. It was the compliance logic that nobody could explain. It was the manual workarounds that staff had invented because the automation didn’t actually automate.

What We Built

We replaced 608 Salesforce components with a 12-bounded-context system built entirely on commodity open-source infrastructure: PostgreSQL, FastAPI, React, Temporal for durable workflows, Celery and Redis for background tasks.

The compliance engine — previously that six-component nightmare I described — became a single pure-Python evaluator using CEL (Common Expression Language) for conditional rules. One file. Testable in isolation. Deterministic. It produces structured gap reports that tell you exactly why a vendor is non-compliant, down to the specific coverage amount that falls short.

Every architecture decision is documented in 37 ADRs (Architecture Decision Records). Not because we enjoy writing documents, but because the next team that touches this codebase shouldn’t have to reverse-engineer it the way we reverse-engineered the Salesforce org.

The migration itself moved 509,000 records through an 8-wave ETL pipeline. Each wave processes related Salesforce objects in dependency order — organizations first, then relationships, then compliance data, then financials. Every wave is idempotent (safe to re-run), transactional (rolls back on error), and validates results with row counts, foreign key integrity checks, and business rule assertions.

Over 1 million lines of Salesforce export were analyzed to map the full dependency graph.

The Hard Parts

I’ll be honest about what nearly broke us.

The junction table problem. We expected client-vendor relationships to live in the junction table Salesforce provides for that purpose. It had 2 records. Two. The actual 9,518 relationships were hiding in a lookup field on the Account object. The migration had to reconstruct every relationship from that field, generating synthetic invitation records marked MIGRATED for traceability. If we hadn’t caught this, we’d have launched with 99.98% of relationships missing.

Formula fields as truth. Salesforce formula fields look like data, but they’re computed values. You can’t query them reliably, you can’t trust them as source of truth, and when you try to migrate them, you realize the formula itself is the business logic — not the value it produces. We had to reverse-engineer 90+ formulas to understand what the business actually intended, then implement that intent as explicit, testable code.

Encrypted field migration. Tax IDs, payment data, W-9 information — all of it needed application-level encryption in the new system. We built a staging-first architecture where plaintext lives in staging tables during migration, gets encrypted transparently through a SQLAlchemy TypeDecorator on flush, and then staging tables are truncated. It sounds simple in retrospect. It wasn’t.

The “obsolete” Flows that weren’t. Remember those 25 Flows marked obsolete? Three of them were still being triggered by other automation. Removing them would have broken compliance status updates for about 800 vendor accounts. We only caught this because we traced every execution path before decommissioning anything.

The Outcome

The new system has 4,000+ backend tests at 98% coverage. The compliance engine that used to be unexplainable is now a function you can call with a vendor ID and get back a structured report in milliseconds. Feature requests that took three months in Salesforce take days.

The migration pipeline is a tool, not a project. We ran it in dry-run mode dozens of times against production data copies before the actual cutover. The cutover itself was a discrete event — not a gradual, painful transition where you’re running two systems for 18 months.

Salesforce licensing goes away entirely. The new system runs on standard Docker infrastructure deployable to any cloud provider.

I won’t pretend it was easy. But the total build — schema design, ETL pipeline, compliance engine, workflow system, frontend, and full test suite — was completed in roughly 30 working sessions. Not 30 months. 30 sessions.

Should You Do This?

Not everyone should. If you actually use Salesforce as a CRM — pipeline management, forecasting, opportunity tracking — stay where you are. That’s what it’s built for.

But if you recognize your situation in any of these, we should talk:

You have 20+ custom objects and your Salesforce admin says every change takes months
Your compliance or business logic is spread across Flows, Apex, formulas, and batch jobs, and nobody can explain the full evaluation chain
You’re paying per-seat licensing for an operational tool that isn’t a CRM
Your vendors or partners need a real portal, not Experience Cloud
Your Salesforce org is technical debt that everyone is afraid to touch

The sweet spot is companies with 50–500 employees, $150K–$800K/year in Salesforce spend, in regulated B2B industries — oil and gas, construction, logistics, manufacturing, environmental services. Companies where compliance tracking or vendor management is the core business process, not a side feature.

If that sounds familiar, book a call. We’ll start with a Salesforce Operational Audit — a fixed-price, read-only assessment that maps your entire org’s complexity, traces the dependency graph for your critical business processes, and gives you an honest migration feasibility report. It’s valuable even if you decide not to migrate, because most companies have never actually seen a complete inventory of what their Salesforce org has become.