There is a real Salesforce importer, a CSV path for leads and contacts, and an API that takes everything. None of the three has a screen yet, 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. What none of them has is an interface, so every one is 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 ships in the enterprise edition, not the community one.
Contacts import in two steps, preview then commit, so you see every row error before anything is written. Leads take a single upload that hands off to a background job and tells you nothing about what happened to each row. Both cap at 5 MB and neither is wired into a screen. Accounts have no import at all, and there is no Excel path.
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 | CSV | JSON API |
|---|---|---|---|
| Accounts | Salesforce importer | No CSV import | Yes |
| Contacts | Salesforce importer | Preview and commit | Yes |
| Leads | Not mapped | Single upload | Yes |
| Deals | Salesforce importer | No CSV import | Yes |
| Products | Salesforce importer | No CSV import | Yes |
| Invoices and quotes | Quotes and orders | No CSV import | Yes |
| Tickets | Not mapped | Preview and commit | Yes |
| Tasks | Not mapped | No CSV import | Yes |
The Salesforce importer is in the enterprise edition. A community self-host has the CSV 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 in the system that already has search and merge than in the one you are moving to. BottleCRM has no merge for contacts or accounts, so a duplicate you bring across is a duplicate you keep.
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.
Deals move through six fixed stages: Prospecting, Qualification, Proposal, Negotiation, Closed Won and Closed Lost. You cannot rename them or add your own, so a nine-stage pipeline needs a decision about what collapses into what before any data moves.
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.
BottleCRM has no CSV export of its own, so the file you exported from your old CRM is your only copy of the before state. Keep it until you are certain, and keep a database backup afterwards, 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.
Every importer that exists is an API. Nothing in the web app or the phone has a screen that connects a source system, uploads a file, or shows you an import running. This is the single 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.
There is nothing to recreate them into. BottleCRM has no workflow engine, no automation rules and no triggers. Escalation on a ticket and recurring invoices are the two scheduled behaviours in the product, and both are configuration rather than a rule you write.
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 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.
Not yet, and this is the honest shape of it. Contacts have a proper two-step importer with per-row error reporting, and leads have a one-shot upload, and neither is wired to a button in the web app or the phone. The Import control on the leads list is not connected to anything. Until it is, a CSV migration is an API call.
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 that collapse into one of six, 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 no workflow engine and no automation rules, so a process that depends on branching automation does not have a home here. Ticket escalation and recurring invoices are configuration, and everything else 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.
