How to handle Salesforce's data limits, how to fully export all your data, and how a migration to an open, in-house data layer works without data loss.
Salesforce is a strong product with a business model that starts working against you as you grow: per-user licenses, tight data limits and expensive storage make your own customer history costlier every year.
Working strategies exist for the data limits, and the best of them, archiving to your own database, is immediately the first step toward in-house management.
All your data comes completely out of Salesforce: the export routes exist, you just need to know which route applies to which data and how to keep relationships between records intact.
A migration to an open, in-house data layer is therefore not a leap into the unknown but a controlled process, with a test migration and a period of running in parallel before anything at all gets cancelled.
Salesforce more or less invented the modern CRM. It moved customer data from local servers to the cloud, made sales measurable, and built a complete ecosystem around it. For businesses that wanted to sell more professionally ten or fifteen years ago, it was a sound choice, and the investment in setup and adoption has often proven worthwhile.
But the model underneath that success has stayed the same: you rent access to your own customer data, per user, per month. Everything you add, every record, every attachment, every point of contact, makes the package more valuable and leaving harder. That's not a criticism; it's simply how the business model works. The only question is whether it still fits you now that an alternative exists.
Salesforce's bill consists of more than the amount per user per month. Three items quietly grow along with your business.
Every new colleague is a new license, and list prices have been raised several times in recent years. Features that used to be included move to more expensive editions or add-ons. Customers of ten years rarely still pay the rate they originally signed up for.
The storage that comes with your licenses is limited: the data limit for an average org starts at around ten gigabytes, plus a small allowance per user. That sounds generous, but every record counts, and an active sales team with email integration and attachments fills that space within a few years. Extra storage is then bought in small blocks at prices that, per gigabyte, are a multiple of what storage costs elsewhere.
The API, reports and automations also have limits per day or per org. If you want to use your own data at scale for an integration, a data warehouse or an AI application, you run into those limits or pay for wider access. The strange part is rarely said out loud: you're paying for access to data that is already yours.
Even if you stick with Salesforce for now, you don't have to accept the storage bill. Three strategies, increasing in effect.
Every org that's a few years old contains duplicate accounts, orphaned contacts and tasks that were never closed out. Structural cleanup often frees up ten to twenty percent of space and also makes every report more reliable. Do this before anything else: it's also the first step of every good migration.
Files are the biggest consumer of storage. Quotes, contracts and email attachments belong in cheap document storage, with only a reference left in Salesforce. That immediately saves on the most expensive storage category.
The structural solution: move closed records, old activities and history to your own PostgreSQL database, where storage costs almost nothing and everything stays searchable. This is the most interesting strategy, because that archive database is, in effect, already an in-house data layer. Once you have one, you usually quickly discover that reports and AI applications run more easily on it than on Salesforce itself. The rest of this whitepaper is the logical next step of exactly this idea.
Your data comes completely out of Salesforce, but not all of it the same way. These are the routes.
The built-in export function delivers a zip with CSV files per object: accounts, contacts, deals, tasks, custom objects. For large volumes and repeatable exports, the Bulk API is the tool.
Every relationship runs through Salesforce IDs in the export files. Carry them over and convert them correctly, and every contact stays linked to the right account and every deal to the right contact.
Files live in their own object structure and don't automatically come along with the standard export. They're retrieved separately through the API and linked to the right records.
Points of contact sit in tasks and email objects and are exportable. Check that the link to the right people comes along too: this is where sloppy migrations lose history.
Change history sits in separate history objects with a limited retention period. If you want to keep it, export it early in the process.
Nothing on this list is secret or withheld: Salesforce cooperates cleanly with export. The difference between a complete migration and a botched one isn't about access, it's about knowing these routes and checking the result.
The export is half the work. The other half is the actual transfer, and that's where migrations that looked fine on paper go wrong. Five rules that make the difference.
First accounts, then contacts, then deals, then activities and attachments. Keep a mapping per record from old ID to new ID, so every relationship is traceable and every mistake fixable.
Everything into a test environment. Recount per object: the same number of accounts, contacts and deals as in the source. Spot-check the relationships and the odd cases, such as records without an owner.
Deduplicate and normalize while you're looking at every object anyway. Document what you deliberately leave behind, so "left behind" never means "lost".
The new environment proves itself alongside Salesforce first, with real reports on real data. Only once the team trusts it do you wind down licenses.
Flows and automations can't be exported, and that's an opportunity. Rebuild what your process actually needs, the way your team works, and leave the rest out.
Where do you migrate to? And Repeat's answer isn't another package, because then you'd just be moving your lock-in. The answer is an AI Native Data Layer: an open, central data layer on PostgreSQL, fully in your own hands, that all your business software connects to.
Your customer data forms the foundation. On top of it, solutions get built that you'd expect from a CRM, but shaped around the way you work: pipeline and follow-up, dashboards, AI chat that answers questions about your own customers, agents that take over routine work. Every solution on top is interchangeable without data loss, because the data sits underneath it, not inside it.
The cost model follows along: no per-user licenses, only low and predictable infrastructure costs. And because the data layer is open and portable, you can always take it with you. Away from us too; that keeps everyone sharp. How that platform fits together is explained in full in the whitepaper on the AI Native Data Layer.
| aspect | salesforce | in-house |
|---|---|---|
| costs | License per user per month, with recurring price increases and add-ons | Low, predictable infrastructure costs, regardless of the number of users |
| storage | Tight limits, extra storage in small, expensive blocks | Virtually unlimited at regular database costs |
| access to your data | Through exports and an API with daily limits | Direct: it's your database |
| processes | Your way of working adapts to the package's data model | Every solution is built around your way of working |
| AI on your customer data | Through the vendor's AI products and limits | Every AI application connects directly to your own data layer |
| ownership | Renting access to your own customer history | Data, environment and history are fully yours |
Europe has recognized the switching problem and turned it into legislation. The Data Act requires cloud service providers to make switching practically possible: handing over your data in a common, usable format and not frustrating the switch. From 12 January 2027, no switching costs may be charged for this either.
For anyone on Salesforce, that means the door will soon be legally open. But a law doesn't export your data and doesn't build your new environment. Anyone who wants to be free to choose in 2027 would do well to get to know their own data now and explore the route. More on this in our article on the Data Act and switching costs.
Every good migration starts with knowing what you have. That's why the first step is always a data scan: we look through your org together and map out which objects and volumes exist, which integrations and flows are running, and what the quality of the data is. With a test export, we show you what your data looks like in an open data layer.
After that, you know exactly where you stand: what needs to move, what can be cleaned up and what the migration involves. Even if the conclusion is that staying put is the best choice for now, because that happens too, you'll have a documented picture of your own data. That's never wasted work.
And Repeat helps SMEs bring their data and software fully in-house, with an AI-native data layer as the foundation. Migrations out of CRM packages like Salesforce are a logical part of that: the data is already there, it just needs to go back to its owner. One conviction runs through everything: your data and your software should belong to you, not to a vendor.
Book a no-obligation data scan. We'll map out your org and use a test export to show you what your data looks like in-house. Honest advice, even when that advice is "stay put for now".