Move to Salesforce without moving the problem
Most migrations start with the data, but the real opportunity is much bigger. A migration gives you the chance to decide what the new Salesforce org should look like: keeping what works, simplifying what does not and making sure the platform reflects how the business needs to operate today.
It is a natural point to review fields, automation and processes, remove what is no longer useful and improve what could work harder. Done well, you do not just arrive with cleaner data. You go live with a simpler, better organised Salesforce platform that is easier to use, manage and build on.
These are some of the common platforms we migrate from, but the source system is rarely the constraint. We work out the right migration approach and tools for each situation. If your existing system holds the data, there is almost always a practical route to move it.
Three things migrate, not one
- The data. Accounts, contacts, opportunities, history and attachments. Mapped, de-duplicated and reconciled against a source of truth that somebody has agreed to.
- The process. How the work actually runs, which is rarely what the old system was configured to do. This is where a migration either improves the business or reproduces it.
- The debt. The rules, fields, workflows and integrations that accumulated over years. Some of it is load bearing. Some of it has not run since 2022. Knowing which is which is the work.
Budget usually covers the first. The second and third are where the value is, and they are the ones most often left out of a quote.
Unwinding what accumulated
Every org that has been running for a few years carries decisions nobody remembers making.
The pattern is consistent. An automation was built to solve a problem that mattered at the time. The person who built it moved on. Nothing was written down. The new admin inherits something that clearly does something, cannot say what, and is not willing to switch it off to find out. Multiply that by five years and you have an org that works, in the sense that nobody has proved otherwise.
Migration forces the question. Every object, field and automation either earns its place in the new org or it does not come across. That is uncomfortable, and it is also the only time you get to ask without it being a separate project with its own business case.
The inventory is therefore not an administrative step. It is where the client finds out what they have been running. We have had sessions where the most useful outcome of the week was a list of eleven automations nobody could account for, three of which were contradicting each other.
Nothing is switched off on the strength of an assumption. Anything unexplained is documented, tested in a sandbox, and retired with a record of what it did.
What a migration lets you fix
The five pillars are usually addressed one at a time, each needing its own justification. A migration is the one project where all five are already in scope.
How we run a migration
Rehearsal is not optional. A migration that has only been run once has not been tested, it has been attempted.
The question to settle before you migrate
How much of the old system are you willing to leave behind.
It sounds like a technical question and it is entirely a commercial one. A lift and shift is faster, cheaper and lower risk, and it gives you the same business in a different system. A redesign costs more, takes longer, and is the only version that changes anything. Both are legitimate. What causes trouble is starting one and finishing the other.
The second question is what happens to history. Everything, everything for a period, or a summary with the detail archived elsewhere. Each has a cost, and the decision affects the storage bill for as long as the org exists.
We ask both in the first conversation, because the answers change the shape of the work more than the source system does.
Systems we migrate from
Most work comes from a small number of sources, but the source is rarely what determines the difficulty.
- Another CRM. HubSpot, Pipedrive, Zoho, SugarCRM and Dynamics 365 are the ones we see most. Object models differ, and the mapping is a design decision rather than a lookup.
- Spreadsheets and shared drives. More common than anyone admits, and often the hardest, because the rules exist only in somebody’s head.
- An older Salesforce org. Consolidation after an acquisition, or a rebuild where the existing org carries more debt than it is worth unwinding in place.
- A bespoke or legacy system. If it has a database or can produce a file, it can be moved. Working out the tooling and the path is the specialism.
We are not tied to one migration toolset. The right tool depends on volume, object complexity and how much transformation happens in transit, and that assessment is part of the scoping rather than a licence we are trying to place.
Start with what you are moving from
Tell us the source system, roughly how many records, and whether anything is driving the timing. That is usually enough for us to describe the shape of the work.
If you are not sure whether to migrate or rebuild in place, a Landscape Review answers that with evidence.
Salesforce migration: frequently asked questions
It depends far more on the decisions than the data. Where the process is agreed and history rules are settled, a single-source migration is usually weeks. Where those are open, agreeing them is the project and the load is the short part.
Yes. Working out the tooling and the extraction path is the specialism rather than a limitation. If a system holds data and can produce a file or expose an API, it can be moved.
During. De-duplicating records in place is a project in its own right. De-duplicating in transit is a mapping decision, and the same work costs a fraction of the price.
That is a decision rather than a default. Everything, everything for a defined period, or a summary with the detail archived outside Salesforce. Each carries a different storage cost for the life of the org.
Some of them. Part of the inventory is establishing what each automation does and whether anyone still relies on it. In most orgs a meaningful proportion has not run in years, and rebuilding it would be paying to carry a problem across.
Yes. Handover is built into the method, and the documentation produced during the inventory is written to be used by your admin rather than filed. Ongoing support is available if you want it, not assumed.