We Replaced Salesforce With Notion in Eight Weeks

How BitSafe Runs on Notion, Part 4 of 5

We turned off Salesforce after an eight-week migration.

The change attracted attention because Salesforce is the kind of system companies assume they will keep forever. The more useful part of the story is what we refused to recreate.

We did not build a smaller copy of Salesforce inside Notion. We redesigned the CRM around the way BitSafe already worked, then migrated the records and automations that still earned their place.

Salesforce was decommissioned when the active workflow had moved. The result was a simpler operating system with customer context connected to the rest of the company.

This is the migration story. The separate field report, We Built a CRM Most Employees Rarely Need to Open, covers the day-to-day conversational experience in more detail.

Salesforce had become the main system that sat outside our shared workspace.

Projects, meetings, documents, product context, and our internal knowledge base lived in Notion. Customer records lived elsewhere. Any question that crossed that boundary required an integration or a person to reconcile the answer.

The issue was not that Salesforce failed at CRM. It was that the separation no longer matched our operating model.

A partner conversation might affect a project, produce a meeting note, create a follow-up, and change an opportunity. Keeping the opportunity in a separate system made the relationship harder to see. It also meant agents and workflows needed different routes for reading context and writing updates.

We wanted one structured record connected to the work around it.

We wrote down what the replacement had to do before changing the schema.

The active records we used needed a Notion equivalent. Important automations had to be rebuilt, replaced, or retired deliberately. Leadership needed the reports it actually reviewed. The team needed a capture path at least as convenient as the one it was leaving.

We also set non-goals.

Historical complexity did not deserve automatic preservation. We would not reproduce every object, field, report, or automation because it existed. We would not migrate every old record into the live workspace on day one. We would keep the external tools that still served a distinct job.

Those constraints prevented the migration from becoming an imitation exercise.

The first week focused on the data model.

We identified the minimum records needed for active relationship management, then connected them to the company directory, applications, meetings, documents, and tasks already in Notion.

Required capture fields stayed limited. Optional metadata had to support a real decision or workflow. Status options reflected the stages the team used rather than the stages inherited from the old system.

We also removed a separate Leads object. In our model, an early relationship can remain a company with an appropriate status until more specific work exists. That eliminated a recurring handoff between two records representing the same organization.

The lesson from this phase was clear: migrating data before redesigning the model only carries old friction into a new tool.

The capture layer came before the finished dashboards.

Employees could add or update CRM information through familiar surfaces, including Slack and Notion. Each route wrote to the same underlying records. The database remained the system of record without forcing every employee to use the database view as the main interface.

This was the point when the migration became real for the team. A CRM succeeds when information enters it during normal work, not when people promise to clean it later.

The conversational experience is covered in the standalone CRM article. For the migration, the key fact was simpler: the replacement needed a reliable write path before leadership reporting could matter.

Once the team was entering live data, we built the views leadership and operators used regularly.

We did not migrate every report. We identified the questions that still shaped decisions and rebuilt those against the new schema. Feedback changed the layout because the first useful draft revealed which groupings and exceptions people actually needed.

Automations followed the same rule. Fixed routing belonged in deterministic tables and workflows. Interpretation-heavy capture could use agents within a constrained schema. Hygiene checks surfaced malformed or stale records without turning every exception into another meeting.

This phase confirmed why dashboards should come after capture. A polished report cannot compensate for a write path employees avoid.

The middle of the project was an automation audit.

For each remaining Salesforce dependency, we asked four questions: what does it do, who depends on it, should it move, and what should execute it after the migration?

Some workflows were rebuilt in Notion. Some stayed in a specialist external tool with a new destination. Others were retired because they no longer supported a current decision.

Historical records were exported and retained outside the live operating surface. Active work received priority. This kept the migration focused on continuity rather than completeness for its own sake.

The audit was less visible than the new CRM. It carried more shutdown risk. A subscription can only be turned off safely when the quiet dependencies have been found.

By the final week, the team had already been operating in Notion. Active workflows had moved, required reporting was available, and the dependency audit was complete.

We decommissioned Salesforce and kept the historical export available if needed.

The transition felt smaller than expected because the new system had become normal before the shutoff. That is a better sign than a dramatic launch. Infrastructure changes should disappear into the work once they are ready.

Several choices made the new CRM easier to maintain.

We used fewer record types. We removed fields nobody used. We dropped reports that did not influence a recurring decision. We kept specialist tools when they still performed a clear job, instead of forcing every function into Notion.

Most importantly, we treated customer context as part of the company system rather than a separate universe. Meetings and tasks could relate to the same records without maintaining a second identity layer.

The operating lesson is to migrate outcomes, not software shapes.

We would complete the automation inventory before the first build week. Discovering quiet dependencies during the middle of a migration adds uncertainty when the team is already adapting.

We would lock the core schema earlier. Changes to a live field can affect views, workflows, and agent instructions at once.

We would also hold back unfinished dashboards. Early feedback is useful, though a half-built executive surface can reduce confidence in good underlying work.

The eight-week timeline worked because the wider Notion architecture already existed. This was a CRM migration inside an established company system, not a simultaneous rebuild of every operating process.

That distinction is important. We did not leave Salesforce to save a line item or prove that Notion can replace every specialist tool. We left because one connected source of truth fit the company we had built.

Subscribe to the BitSafe newsletter for more from the Canton ecosystem and occasional field notes on how BitSafe operates.