We turned off Salesforce in May 2026.
This article is about why, how, and what we'd do differently. It's the most concrete proof point we have for the thesis of this series — that a well-designed Notion substrate plus the AI layer on top of it can replace a category of SaaS that most companies treat as untouchable.
We don't think every company should make this move. We do think most companies overestimate the switching cost and underestimate what they're paying for the status quo. Here's how it played out for us.
Why we left Salesforce
Three things drove the decision.
Our CRM had become an island. Everything else at BitSafe had migrated to Notion. The product roadmap, the partner directory, the Canton ecosystem app catalog, the meetings system, the SOPs, the agent skills — all in Notion. The CRM was the one big database that was somewhere else, which meant every cross-system question (what did we tell this partner, which deals depend on which Canton apps, which marketing campaign produced which opportunity) became a manual reconciliation.
The agent layer didn't reach across the boundary. NanoClaw could query the Notion side natively. It synced Salesforce into a local SQLite cache, but writes had to cross the API boundary, and a meaningful share of agent work needs writes — capture an opportunity from a Slack message, update a stage from a meeting summary, log an outreach. Two systems doubled the surface area we had to keep secure and the prompt complexity required to get good answers.
The bill. Salesforce is expensive. The total cost of ownership — license, integrations, the engineering time to keep the integrations working, the consulting required to make any meaningful change — was meaningfully higher than what Notion costs us. We don't make this decision on price alone, but the numbers were honest.
The thing that wasn't a reason: dissatisfaction with Salesforce as a product. Salesforce is good at what it does. It just wasn't the right tool for the architecture we were building.
What "good enough" had to look like
Before we touched anything, we wrote a one-page document of what the new system had to do. This is the document that the rest of this article is downstream of.
Every Salesforce object we used had a Notion equivalent.
Every active Salesforce automation either had a Notion equivalent or had been explicitly deprecated.
The sales team could capture opportunities, companies, apps, and contacts as fast as or faster than they could in Salesforce.
Reporting and dashboards covered every chart leadership actually checked weekly.
The Salesforce-side BDR tooling (Salesloft, in our case) kept working without disruption — we weren't changing the BDR motion, just where its outputs landed.
The non-goals were equally important.
We did not try to migrate every historical Salesforce automation. Most of them were doing reporting that we'd just rebuild in Notion natively.
We did not try to perfectly mirror Salesforce's object model. Our Notion CRM has fewer object types than Salesforce did, and that was the point.
We did not migrate every historical record on day one. Active opportunities migrated immediately; closed-won and closed-lost archives were exported and parked, available if we needed them.
The eight-week sprint
The actual work broke into roughly four phases.
Week 1: Data architecture
The full schema redesign. We split Type into Category + BitSafe Role on Companies. Added Region, Company Size, AUM/Revenue Band, ICP Segment, MSA Status, BitSafe Products of Interest. Built the new hybrid Partnership Status pipeline (Prospecting → Qualified → Scoping → Integrating → Live Partner) as a Status property, not a free-text field. On Opportunities, we locked four required fields at capture (Company, Product, Close Date, Sales Stage) and made everything else nice-to-have. We built the flexible Opportunity ↔ Company / Opportunity ↔ App relations that let the same opp roll up multiple ways.
The thing we tried hardest not to do in week 1 was build a Salesforce mirror. Salesforce had Leads as a separate object; we don't, because in our world a "lead" is just a Company with an early Engagement Status. Salesforce had Forecast Category, Node Operator, Custodians/Wallets, and Source/Referred By; we don't, because the team didn't use them. The schema fit how the team actually worked, not how the previous system was shaped.
Week 2: The capture layer
This is the week the work became real for the sales team. We shipped the CRM Capture Agent in three surfaces — Slack (#bd-ai-crm), the Notion AI sidebar, and traditional forms — all writing into the same databases.
The Slack agent was the breakthrough. Drop a one-line message describing what happened ("Closed Won with Rho Labs DEX, MSA signed today"), the agent replies in-thread to ask any clarifying questions, and the row is in Notion before the reply gets read. By Wednesday of week 2, our BDR was using it in production.
Week 3: Reporting, dashboards, and automations
The first sales dashboard shipped in week 2 as a draft; week 3 we iterated on it based on real feedback (replace the kanban with a table by stage; remove Recently Closed; surface Commits prominently; add hygiene flags for Closed Won missing MSA or Party ID).
We also stood up the CRM Hygiene Monitor described in Part 3 — four daily checks, posting to #crm-alerts. Lead routing migrated to a Notion lookup table plus an n8n trigger. The Reporting skill landed: ask the Slack agent for a pipeline summary, partner status, app ecosystem, activity, project, or custom view, and it generates a linked database view with headline stats.
Weeks 4–7: Migration, automation audit, and the long tail
This is the unglamorous middle of the project. We catalogued every Salesforce automation still touching our sales workflow — what it did, what it depended on, whether we needed to rebuild it in Notion, replace it, or kill it. Our consulting partner at KinCloud (Filip) handled most of this with us.
Dropbox Sign flows went through their own decision tree (some kept, some replaced with Notion-native equivalents). We rebuilt the Salesforce Reveneer SDR KPIs dashboard in Notion's new Dashboards view — it had been our strongest Salesforce report, and we weren't willing to lose it. The Transition Dashboard (movement counts by stage by week) got built natively against an Event Log database that NanoClaw populates on every state change.
Week 8: Shutoff
With every active workflow migrated, every dashboard rebuilt, and the team operating in Notion for two weeks, we cut the Salesforce subscription. The historical export sits in cold storage. Nobody has asked for it.
What helped
A few things that made the timeline possible.
The substrate was already there. This is Part 1 and Part 2's whole argument. We didn't have to build the Pillars→Projects→Tasks spine, the Documents database, or the Meetings system during this sprint. They were already in production, which meant the CRM build was just the CRM build.
The Capture Agent moved before the dashboards. A common migration mistake is to build the leadership dashboards first because they're visible. We built capture first because if the team can't easily put data in, none of the dashboards matter.
Forms, sidebar, and Slack all wrote to the same place. Every team member picked their preferred surface. The data was identical. We didn't have to debate which UX would win.
Locked schemas + AI capture + autofill enrichment. This combination is the closest thing to a free lunch we found. The team enters minimum-required information conversationally, autofill completes the rest, and the CRM is cleaner than Salesforce ever was.
What didn't transfer (and why we didn't miss it)
Salesforce's complex object model. We replaced six object types with three. The fewer types you have, the less your team has to think about which one to use.
A separate Leads database. Folded into Companies via Engagement Status.
Most of the historical Salesforce reports. Half of them were reports about reports. We rebuilt the ones leadership actually opened weekly and dropped the rest.
Salesloft (our BDR sequencer) stayed. We never planned to replace it. The BDR motion writes back into Notion via the Updates and Event Log databases.
Dropbox Sign flows mostly stayed too, with their write destinations rerouted to Notion.
What we'd do differently
Lock the schema in week 1, fully. We let a few Companies fields drift in week 2 and paid for it in week 3. Schema changes invalidate views, dashboards, and the AI agent's understanding of which fields to ask for. Lock the schema, then build on top.
Don't let the team see a half-baked dashboard. The first sales dashboard we shipped was deliberately rough. It was useful internally as a checkpoint. It was almost a problem externally — the team's first impression matters. Next time, we'd dashboard last.
Plan the Salesforce automation audit before starting the migration, not in the middle. We did this in week 4–5. It should have been week 0–1, even if some entries had to be filled in as we went.
Outreach and response tracking should be modeled before capture. We built capture first and then realized we hadn't decided what an "outreach" or a "response" was. We worked it out, but it was avoidable rework.
What it was actually like
It was less dramatic than expected.
The team kept their morning. They closed deals. (Two MSAs got signed in the middle of the migration; both are Closed Won in Notion now.) The 16-hour-flight stand-up the day Aki landed from a trip happened on the new system without anyone noticing it was the new system. Our BDR entered records in Slack from his couch. Leadership read pipeline numbers off a dashboard that didn't exist three weeks earlier.
The biggest surprise wasn't the migration itself. It was how much smaller the company felt afterwards. One CRM. One source of truth. One agent layer that could read and write everywhere. Fewer integrations to keep alive. Fewer reconciliation jobs. Fewer "where do I find that" questions.
That's the thing the eight weeks bought us. Not a cheaper CRM. A simpler company.
Keep reading
Start with the hub: The Infrastructure Mindset, Turned Inward — How BitSafe Runs on AI
How BitSafe Runs on Notion — the brain:
Part 1: Notion as the Company OS · Part 2: The Architecture · Part 3: Agents, Automations, and the AI Layer · Part 4: Replacing Salesforce with Notion · Part 5: The Agent Governance Model
The NanoClaw series — the reach:
Part 1: Building a Company-Wide AI Assistant · Part 2: The Architecture · Part 3: The Autonomous Engine · Part 4: The Substrate · Part 5: Working With NanoClaw · Companion: Cost Discipline
Standalone deep-dives: