Should You Build Your Own CRM? A Realistic Checklist for Migrating Off Salesforce onto AWS + PostgreSQL

Why this conversation keeps coming up

Every mid-market company running Salesforce has had this meeting at least once. Someone runs the numbers on the renewal, someone else pulls up a Klarna headline, and by the end of the hour there’s a Slack channel called #life-after-salesforce.

The math that starts the conversation is real. A 300-seat Enterprise Edition deployment lists at roughly $630,000 a year in Sales Cloud licenses alone, before you add the Premier Success plan at 30% of net license fees, before Shield security add-ons that run 10–30% of net spend, and before the API access, Field Service, or Agentforce line items that show up once you actually try to use the platform the way it was demoed to you (Salesforce Sales Cloud pricing; Redress Compliance). Salesforce also raised list prices by an average of 9% in August 2023 and another 6% in August 2025. That is two increases in two years, on a bill that was already six figures (Salesforce Ben; Salesforce newsroom).

Then someone mentions Curative, the health-insurance startup whose CEO announced he’d cancelled a $600,000-per-year Salesforce contract after his team built a replacement CRM with AI assistance in about two months (Yahoo Finance / Business Insider). Or Klarna, which dropped Salesforce and built a homegrown system that reportedly does the work of 700 contractors and saves roughly $40 million a year (TechCrunch).

Those stories are true. They’re also survivorship bias wearing a good suit. This paper is the version of that conversation nobody puts in the pitch deck: the actual checklist, area by area, of what it takes to replace Salesforce with a custom CRM on AWS and PostgreSQL, plus the honest math on when that trade is worth making.

We’re writing this for a specific, common shape of company: 200–2,000 employees, $50M–$1B in revenue, running Salesforce Sales Cloud and Service Cloud as the operational backbone for sales and customer support. If that’s you, keep reading. If you’re a 15-person startup with one Salesforce admin and no compliance obligations, a lot of the cost structure below doesn’t apply to you the same way. The calculus changes at scale, in both directions.

The bottom line, up front

Building a custom CRM is not a technology project. It’s a decision to become a software company, on top of whatever business you already run. Every dollar you stop sending to Salesforce gets redirected somewhere, mostly into engineering payroll, not AWS invoices.

The infrastructure is genuinely cheap. A production-grade AWS environment for a several-hundred-user CRM (Multi-AZ PostgreSQL, an application tier, load balancing, object storage, backups) runs in the neighborhood of $1,600–$5,000 a month (derived from AWS RDS, Fargate, ELB, and S3 price lists). That’s roughly what ten Salesforce Enterprise seats cost. Infrastructure was never the reason to stay on Salesforce, and it isn’t the reason to leave either.

The team you need to build and run that infrastructure is the real number. A realistic build-and-maintain team (a few backend engineers, a DevOps/platform engineer, a database architect, a QA analyst, a fraction of a security analyst) runs roughly $800K–$1.1M a year in fully loaded compensation using current U.S. median wage data (BLS Occupational Outlook Handbook; ZipRecruiter). Compare that to the one or two Salesforce admins most mid-market orgs run today, at roughly $99,000 each (ZipRecruiter). That delta, $600,000 to $900,000 a year, is the single most commonly omitted line item in the “we’ll just build it ourselves” pitch, and by itself it often exceeds the entire Salesforce license bill you were trying to escape.

None of this means don’t do it. It means go in with your eyes open on where the money actually goes, and this paper is built to help you do exactly that: company by company, department by department, and system-area by system-area.

Who this is for: a sales and support-centered mid-market org

Picture a 400-employee company: 60 sales reps and managers running pipeline through Sales Cloud, 120 support agents working cases through Service Cloud, a RevOps team maintaining the automation and reporting, and two full-time Salesforce admins keeping the lights on. The company is on Enterprise Edition, has Field Service for a small technician team, uses Shield for field-level encryption because of a customer compliance requirement, and has somewhere between 15 and 40 integrations connected: marketing automation, an ERP, e-signature, a phone system, Slack, a data-enrichment tool.

That is the profile this paper is written around, and it’s a deliberately realistic one: for context, MuleSoft’s 2025 Connectivity Benchmark (a survey of 1,050 IT leaders at organizations with 1,000+ employees) found the average enterprise runs 897 applications, with 71% of them not fully integrated (MuleSoft Connectivity Benchmark Report 2025). Mid-market companies run a smaller version of the same sprawl, and every one of those connections is a rebuild item if you leave the platform that hosts them.

The pros and cons, stated plainly

Why companies consider the move

• License cost compounds every year. Beyond the sticker price, Premier Success runs 30% of net license fees, Shield add-ons run up to 30% more, and storage overages are billed separately. One analysis models overage costs at $1,100 a month for orgs that exceed 1 million records (Nutshell). A $630K license line can quietly become an $800K–$900K all-in bill.
• You own the roadmap. No forced migrations off deprecated features. Salesforce is retiring Workflow Rules and Process Builder on December 31, 2025; if you’re still on legacy automation, you’re rebuilding regardless of whether you leave Salesforce (Salesforce Help). No forced product substitutions like the CPQ end-of-sale in March 2025 that pushed existing customers toward the pricier, less transparent Revenue Cloud Advanced (Technology in Sales).
• You can build exactly what your process needs, instead of configuring around what the platform assumes your process looks like. Off-the-shelf platforms “often do not fit perfectly” and bring rigid workflows and unused feature bloat that you’re still paying for (Webisoft).
• Data ownership and architecture flexibility. Your schema, your indexes, your retention policy, your query patterns, not Salesforce’s object model and governor limits.

Why companies stay, or regret leaving

• You’re trading a subscription for a second engineering org. The fully loaded labor delta alone is often larger than the license bill you’re escaping.
• Compliance gets expensive fast. Salesforce’s compliance program covers SOC 1/2/3, ISO 27001/27017/27018/42001, HIPAA, HITRUST, FedRAMP, PCI DSS, and GDPR out of the box, across Sales Cloud, Service Cloud, and CRM Analytics (Salesforce Compliance portal). Reproducing just SOC 2 Type II on a self-hosted app costs $110,000–$290,000 in year one, with 40–60% of that recurring annually (ComplyGuide).
• The AppExchange ecosystem doesn’t come with you. There is no drop-in replacement for the 6,000+ managed packages your org may be quietly depending on: e-signature connectors, CTI adapters, dedupe and enrichment tools (sfapps.info). Each one becomes a build item.
• Maintenance doesn’t end at launch. Even the CEO who successfully replaced Curative’s CRM in two months called ongoing maintenance “definitely one of the most challenging pieces” of the whole move (Yahoo Finance / Business Insider). Independent estimates put annual maintenance at 15–25% of the original build cost, indefinitely (Entropy).
• The base rate on CRM projects generally is not encouraging. Depending on the source, 47–55% of CRM implementations fail to meet their objectives, and Harvard Business Review’s review of a dozen analyst studies found failure rates ranging from 18% to 69% (Johnny Grow CRM Failure Report). A ground-up custom build carries at least that much execution risk, arguably more, since there’s no vendor roadmap or existing user base to lean on.

The honest framing: migrating away from Salesforce tends to make financial sense when your Salesforce footprint is large and mostly homegrown-workflow already, your integration surface is narrow and well understood, and you already run a real software engineering organization that can absorb a new, permanent product. It tends to be a mistake when your org runs on two admins and forty integrations you didn’t build and don’t fully control.

How to read the rest of this paper

Software, at the level that matters for a CRM replacement, breaks into six parts: database, UI, process automation, integrations/API, security, and analytics. Each section below covers what Salesforce is quietly doing for you today, what it takes to rebuild that capability on AWS and PostgreSQL, and a checklist you can hand to your engineering lead before you commit budget.

1. Database

What Salesforce is doing for you today

Salesforce’s data model handles schema, relationships, sharing rules, and storage limits as one integrated system. Every account, contact, opportunity, and case lives inside an object model with built-in referential integrity, and field history tracking captures up to 20 fields per object by default, or 60 with the Field Audit Trail add-on, which is available only on Enterprise, Performance, and Unlimited editions (Salesforce developer docs). History older than 18 months in production gets automatically archived into a queryable big object, retained until you delete it.

What it takes to rebuild it on PostgreSQL

The actual structured dataset is smaller than people expect. Salesforce meters data storage tightly, and most orgs run on a base of 10 GB plus 20 MB per user license (Salesforce Help), which means the accounts/contacts/opportunities/cases dataset for a mid-market org is typically tens of gigabytes. That is trivial for a single Aurora PostgreSQL instance running at $0.10–$0.225 per GB-month (AWS RDS Price List API). What actually dominates volume is attachments and files, which belong in S3 at roughly $0.023 per GB-month, not in the relational database at all (AWS S3 pricing).

The hard part isn’t storage. It’s extraction and fidelity. A few specifics that catch teams off guard:

• AWS Database Migration Service does not support Salesforce as a source endpoint. It’s built for relational databases, MongoDB, and similar systems. Salesforce requires a CRM-aware connector (Fivetran, Airbyte) or custom code against the Bulk API (AWS DMS documentation).
• Bulk API 2.0 is the only realistic path for a full data pull. Salesforce recommends it for anything over 2,000 records, and it supports up to 150 million records per rolling 24-hour period (Salesforce Bulk API limits). Standard REST API calls are capped at 1,000 requests per user license per 24 hours, nowhere near enough for a full extraction (Salesforce Help).
• Field history lives in a separate big object (FieldHistoryArchive), reachable only through REST, SOAP, or the Tooling API, not through your standard bulk export path. It has to be deliberately re-modeled in Postgres, typically as an append-only history table. This is the single most common place teams say “we migrated the data but lost the audit trail” (Salesforce developer docs).
• Airbyte’s Salesforce connector requires Enterprise Edition, or Professional plus the API access add-on, meaning you may need to pay Salesforce more, temporarily, in order to leave it (Airbyte docs).
• Fivetran prices on Monthly Active Rows, which gets expensive fast against high-churn CRM objects like activities and cases if you’re running it as an ongoing sync rather than a one-time cutover (Fivetran pricing).

Practitioner sources converge on the same list of what actually breaks migrations: source data quality, field-mapping mismatches, broken parent-child relationships, governor-limit throttling mid-load, and incomplete sandbox testing before go-live (Coffee CRM). The standard mitigation is loading records in dependency order and keying on external IDs rather than Salesforce record IDs (Softweb Solutions).

Database checklist

2. UI

What Salesforce is doing for you today

The Salesforce UI is not one screen. It’s list views with saved filters, kanban-style pipeline boards, record detail pages with related lists, global search, case queues, and for support specifically, Omni-Channel routing with both Basic and Advanced (flow-based) modes that assign incoming work to agents based on capacity and skill (Salesforce Help). That routing engine is its own subsystem, not a page you clone.

What it takes to rebuild it

Realistic estimates for a React/Next.js build, from an agency reporting 50+ shipped projects on the current framework versions:

For the whole CRM (frontend plus the backend it talks to), a broader cost guide breaks it down by complexity tier:

A mid-market org replacing Sales Cloud and Service Cloud, with Omni-Channel-equivalent routing, is realistically in the mid-range-to-enterprise band, not the basic one. One credible estimate puts UI/UX design, third-party integrations, and team location together at up to 60% of total development cost (APPWRK). The visible screen is a fraction of the actual bill.

Ongoing cost doesn’t stop at launch. Multiple independent sources converge on 15–20% of original build cost per year for maintenance, widening to 15–25% on more complex platforms (MG Software; Entropy). On a $300,000 build, that’s $45,000–$75,000 a year in maintenance alone, indefinitely.

UI checklist

3. Process automation

What Salesforce is doing for you today

Flow, approval processes, assignment rules, and escalation rules are four separate declarative subsystems doing different jobs (routing, approvals, SLA escalation, and record automation), all configured by admins without code. Salesforce states that record-triggered Flows update records 10 times faster than the equivalent legacy Process Builder automation (Trailhead). One relevant fact for your timing decision: Workflow Rules and Process Builder both lose Salesforce support on December 31, 2025. Existing automations keep running but won’t be fixed or supported, and Salesforce is actively pushing customers to Flow Builder (Salesforce Help). If your org is still on legacy automation, you have a rebuild coming either way, and that’s worth factoring into the timing of a bigger migration decision, not treating as a separate problem.

What it takes to rebuild it on AWS

The AWS-native building blocks for a rules/workflow engine are inexpensive at the unit level:

Even at real volume, say 10 million Step Functions transitions a month, the raw compute cost is about $250; 10 million EventBridge events cost about $10 (AWS Step Functions pricing; AWS EventBridge pricing). As with the database section, the runtime is nearly free. The cost is that Flow is configured by an admin in an afternoon, and Step Functions, EventBridge, and Temporal are configured by an engineer whose fully loaded cost is in the $130K–$180K range. Every approval chain, escalation rule, and assignment logic tree that a Salesforce admin builds declaratively becomes a code review, a deploy, and a maintenance obligation on a custom stack.

Process automation checklist

4. Integrations and API

What Salesforce is doing for you today

This is where migrations quietly blow their budgets. The average enterprise organization runs 897 connected applications, and even at that scale, 71% are not fully integrated, meaning the integration burden is already large and already imperfect before you touch anything (MuleSoft Connectivity Benchmark Report 2025). That survey covers larger enterprises (1,000+ employees); a 400-person company will have a smaller version of the same sprawl, but the same shape of problem: marketing automation, ERP, e-signature, telephony/CTI, data enrichment, Slack, and often a handful of home-grown integrations nobody remembers approving.

Every one of those either uses a Salesforce AppExchange managed package (there were 6,233 apps listed as of December 2025 (sfapps.info)) or connects through Salesforce’s native REST/SOAP/Bulk APIs. There is no drop-in replacement for a managed package on a custom stack. Each one becomes a direct integration you build against the underlying vendor’s API from scratch.

What it takes to rebuild it on AWS

The API layer itself is cheap to run:

• Amazon API Gateway: pay per call plus data transfer, no minimum fee, with a free tier of 1 million calls/month for new accounts (AWS API Gateway pricing)
• AWS AppSync (GraphQL): $4.00 per million operations, $2.00 per million real-time updates (AWS AppSync pricing). A 500-user internal CRM doing 100 million operations a month lands around $400/month

The expense isn’t the API gateway. It’s the long tail of individual connectors behind it. There is no published, reliable per-integration price list, but the best available proxy is that UI/UX design, integrations, and team location together run up to 60% of total CRM development cost (APPWRK), and mid-range builds that include ERP/email integration work run $50,000–$200,000 (Webisoft). That’s before you count telephony/CTI, e-signature, and enrichment tooling as separate line items, which they usually are.

Integrations and API checklist

5. Security

What Salesforce is doing for you today

Salesforce’s compliance program covers Sales Cloud, Service Cloud, CRM Analytics, and CPQ under a single umbrella spanning SOC 1/2/3, ISO 27001/27017/27018/42001, HIPAA, HITRUST, FedRAMP, PCI DSS, GDPR, CSA STAR, and TX-RAMP (Salesforce Compliance portal). Access control runs through a role hierarchy that automatically grants managers visibility into records owned by their reports, layered with org-wide defaults and sharing rules (Salesforce Help). Field-level encryption, event monitoring, and long-term audit trails are available through Shield, at a real cost of 10–30% of net spend, but bundled into a single vendor relationship with a single compliance attestation (Redress Compliance).

What it takes to rebuild it on AWS

The individual AWS security services are inexpensive:

A reasonable security posture for a single CRM workload (encryption, a web firewall, threat monitoring) plausibly runs in the low hundreds of dollars a month. That’s not the real cost.

The real cost is compliance, specifically SOC 2, which most B2B customers will require before they’ll let you store their data in a system you built and host yourself. Independent cost breakdowns converge on:

Annual renewals run 40–60% of the first-year cost, every year, indefinitely (ComplyGuide). A second source corroborates with Type II audit fees of $15,000–$60,000 for most mid-market SaaS companies and notes that the audit fee itself is typically only 40–60% of total program spend (SOC2Auditors). Internal labor alone typically consumes 200–500+ hours, the “biggest hidden cost” according to the same analysis.

This is the section of the checklist most often left out of the initial pitch, and it’s arguably the most consequential: it’s a cost that Salesforce is absorbing on your behalf inside your subscription, and the day you self-host, it transfers directly to you, every year, not just once.

Security checklist

6. Analytics

What Salesforce is doing for you today

Standard Salesforce reports and dashboards come with the platform. For anything beyond that, Salesforce’s own analytics stack (CRM Analytics, formerly Tableau CRM) and Tableau itself carry separate per-user licensing. Tableau list pricing runs Creator $75/user/month, Explorer $42/user/month, Viewer $15/user/month (Vendr), and Tableau was one of the products included in the 2023 price increase (Salesforce Ben).

What it takes to rebuild it on AWS

There’s real optionality here, and it’s one of the few areas where the AWS-native replacement can be cheaper at every tier, not just infrastructure-cheaper:

For 400 read-only users, Tableau Viewer runs $72,000/year; the equivalent on QuickSight Reader is $14,400/year; on self-hosted Metabase Open Source it’s $0 in licensing (Vendr; AWS QuickSight pricing). Many mid-market orgs can skip a dedicated data warehouse entirely and report directly against a read replica of the production Postgres database, which costs the same per-instance rate as your primary database (AWS RDS Price List API).

The catch isn’t tooling cost. It’s parity. A mature Salesforce org accumulates hundreds of saved reports, scheduled dashboard subscriptions, and joined-report logic built up over years. There’s no publishable “hours to rebuild” benchmark for this, and that’s itself a signal: the long tail of reports nobody remembers building, but everybody relies on the third Monday of every quarter, is the actual risk, not the BI tool you pick.

Analytics checklist

Putting it together: the honest total cost of ownership

Here’s the same 300-user, Enterprise Edition company from earlier, compared side by side. Treat this as a framework to plug your own numbers into, not a universal verdict.

The pattern that jumps out: infrastructure was never the deciding factor. It’s roughly the cost of ten Salesforce seats either way. The real trade is a predictable, absorbed-by-the-vendor cost structure (licenses that go up 6–9% every couple of years, but come with compliance, integrations, and a UI already built) versus a lower unit-economics ceiling with a much higher fixed cost floor: engineering headcount and compliance that exist whether you have 50 users or 2,000.

Where this tends to make sense, and where it doesn’t

It tends to make sense when:

• Your Salesforce license spend is genuinely large relative to your engineering budget (multi-million-dollar contracts, not $300K ones)
• Your process footprint is narrow and well-documented, meaning you’re not running CPQ, complex territory management, and a partner portal alongside Sales and Service Cloud
• You already run a real software engineering organization with spare senior capacity, not a team that would need to be hired from scratch for this project
• Your integration surface is small and mostly built in-house already, not dependent on a wide AppExchange footprint
• You’re comfortable owning a multi-year compliance program, not just a one-time certification

It tends to be a mistake when:

• Your entire Salesforce operation is run by one or two admins with no dedicated engineering team behind it
• You have dozens of AppExchange-dependent integrations you didn’t build and don’t have documentation for
• You’re doing this primarily to save money. The labor delta alone frequently erases the license savings
• You have contractual compliance obligations (SOC 2, HIPAA) you haven’t priced into the decision
• Nobody on the team has actually run a software product in production before, with on-call, incident response, and a maintenance backlog

A note on how we approach this at Cloud Nerd

We’re not going to pretend this is a simple yes/no. We’ve sat on both sides of this table: inside 300+ implementation projects, and inside the conversations where a company is trying to figure out whether a rebuild is ambition or avoidance. The honest answer is usually not “should we migrate,” it’s “do we actually know what we’re running today, well enough to replace it.” Most of the checklist above is really an audit of your current Salesforce org disguised as a migration plan, and that audit is worth doing whether or not you ever leave.

If you want a second set of eyes on where your org actually stands against this checklist (what you’re really running, what it would cost to rebuild, and whether the math works for your specific business), that’s a conversation we’re glad to have.