There is a real Salesforce importer, a spreadsheet import for leads, contacts and tickets, and an API that takes everything. Only the spreadsheet import has a screen, which is the first thing this page should tell you and the last thing a migration page usually does.
Nothing here touches your current CRM. Your export stays your export.
Each of these exists in the code today. The spreadsheet import is a button on the list; the other two are an API call or a conversation with us rather than a wizard you click through.
Connect over OAuth and it pulls Accounts, Contacts, Opportunities, Products, Orders and Quotes as background jobs you can watch, cancel and re-run. It is the most complete migration path in the product by a distance. It is also driven entirely through the API today: no screen in the web app or the phone opens it, so using it means calling the endpoints yourself or asking us to run it. It is on the hosted app at app.bottlecrm.io, not in the open-source edition.
Import button on each of the three lists. Leads and contacts take an .xlsx or .csv straight from your old CRM: each column is matched to a field from its header, with Google Contacts, Outlook and HubSpot exports recognised, and the preview shows who will come in and which rows will be skipped before anything is written. Tickets take a CSV with fixed headers, all or nothing. Up to 5,000 rows and 5 MB a file. Accounts and deals have no import.
Every entity is writable over a documented JSON API with JWT auth and an OpenAPI schema, which is how the mobile app talks to the backend. For most migrations off a system with its own export, a script against that API is the shortest route, and it is the one we would use ourselves.
Read across your own row. The API column is uniformly yes, which is the point: it is the only path with no gaps in it.
| Entity | Salesforce importer | File import | JSON API |
|---|---|---|---|
| Accounts | Salesforce importer | No file import | Yes |
| Contacts | Salesforce importer | Any spreadsheet, columns matched | Yes |
| Leads | Not mapped | Any spreadsheet, columns matched | Yes |
| Deals | Salesforce importer | No file import | Yes |
| Products | Salesforce importer | No file import | Yes |
| Invoices and quotes | Quotes and orders | No file import | Yes |
| Tickets | Not mapped | CSV, preview and commit | Yes |
| Tasks | Not mapped | No file import | Yes |
The Salesforce importer is on the hosted app at app.bottlecrm.io. A self-hosted open-source install has the file import and API columns only.
Most of the cost of a migration is decisions, not transfer. These are the decisions, and every one is cheaper to make before the data lands than after.
Duplicates, dead records and inconsistent phone and address formats are cheaper to fix before you move. BottleCRM can merge two leads, contacts or accounts once they are in, but one at a time from the record page, so a file full of duplicates is still quicker to clean in the system that holds it now.
You will recreate them by hand. BottleCRM lets your organisation define fields on every entity, with no code and no migration, and they render on both clients and filter in list views. What it cannot do is guess which of your old CRM’s two hundred fields anybody still uses.
Deal pipelines and their stages are yours to define in Settings, each stage marked open, won or lost. Set them up before any deal moves, so each record lands in a stage that already exists rather than in the six defaults every organisation starts with.
There are two roles, ADMIN and USER, and no permission matrix to configure. Access is role plus ownership plus organisation, enforced in the API. That is the whole model, and it is quicker to map onto than it sounds.
Then look at them in the interface rather than in the response. Formatting, country codes and which field ended up where are all obvious on a record page and invisible in a success message.
The file you exported from your old CRM is your only copy of the before state. BottleCRM can export its own lists to CSV afterwards, but that is what arrived, not what you started with. Keep the original until you are certain, and keep a database backup, because deleting a record here is permanent.
A migration page that lists only what transfers is the one you find out about in week three. If one of these is load-bearing for you, that is worth knowing before you export anything.
A spreadsheet of leads or contacts, or a CSV of tickets, can be imported from the interface. Nothing in the web app or the phone connects to a source system, maps its objects, or moves accounts, deals and their history across. That is the biggest gap on this page, and the reason a managed migration is a service rather than a button.
Salesforce is the only source system with a built importer. For anything else the path is CSV where the entity supports it, and the API where it does not. We would rather name the one than imply the many.
Nothing carries your old workflows across. Simple ones can be rebuilt by hand as automation rules (when a record changes and the conditions hold, set a field, assign, create a task, notify or send a webhook). Branching, waits and anything on a schedule have no equivalent, and recreating rules is not part of the Salesforce importer.
Mail that arrives at a connected mailbox becomes a ticket, threaded against the account it came from. There is no import for the years of correspondence sitting in your old CRM, and no two-way mailbox sync to reconstruct it.
Notes and comments can be written through the API against the record they belong to. The timestamps will be the timestamps of the import, not of the original activity, because created dates are server-derived.
Import jobs can be cancelled while they run. Once rows are written, undoing a migration means restoring the database, which is why the first real advice on this page is to move a hundred rows and look at them.
The importers, the field definitions and the API schema are all in the open repository.
The Salesforce one already exists in the hosted app, and has since before this page said it was coming: OAuth connect, six object mappers, and background jobs you can watch and cancel. What it does not have is a screen, so today it runs through the API or through us. That is a more useful answer than a roadmap date, and it is the one we should have been giving.
Yes, for leads, contacts and tickets, from the Import button on each list in the web app or the phone. Leads and contacts take an .xlsx or .csv: each column is matched to a field from its header, you can change or ignore any of them, and a preview shows who will come in and which rows will be skipped, and why, before anything is saved. Tickets take a CSV with fixed headers, written all or nothing, with a template to start from. Accounts, deals, products and invoices have no file import and go in through the API.
Nothing is lost from your old system, because nothing here touches it. What you can lose is fidelity on the way in: fields with no home, stages you did not recreate before the deals arrived, and activity timestamps that become import timestamps. Move a small batch first and look at it in the interface. Keep your export and take a database backup, since deleting a record in BottleCRM is permanent and there is no recovery log.
A few thousand contacts through the API is an afternoon, most of it spent deciding on the field mapping rather than moving anything. A Salesforce estate with custom objects and years of history is a project, and the honest variable is not the data volume but how much of your old configuration has to be rebuilt by hand.
Yes, and it is one of the things a managed migration is actually for. Custom fields themselves are a first-class feature: your organisation defines them on any entity, they render on the web app and the phone, they filter in list views and they come back through the API. Mapping two hundred legacy fields down to the ones you still use is judgement, and that is the part we help with.
Then this is a real question to settle before you move, not after. BottleCRM has automation rules that act when a record changes: assign it, set a field, create a task, notify people or send a webhook. It has no branching, no waits and nothing that runs on a date, so a process that depends on those does not have a home here. Ticket escalation and recurring invoices are configuration, and the rest is something a person does. Better to hear that now.
The first conversation is about what your data looks like and what you would have to rebuild, not about a price. If the answer is that BottleCRM is the wrong move, we would rather say so at that point than after.
