Migrating from on-prem (Oracle Siebel, SAP CRM, Microsoft Dynamics on-prem) to Salesforce is a major transformation.
Phase 1: Assessment
- Current state inventory — modules used, customisations, integrations, data volume, user counts.
- Pain points — where does on-prem hurt? What's the strategic case for moving?
- Value case — quantify savings (infra, licensing, ops) and improvements (mobile, cloud, AI).
- Constraints — regulatory, data residency, integration with other on-prem systems.
Phase 2: Future-state design
- Salesforce architecture — Sales Cloud + Service Cloud + Industries Cloud + add-ons.
- Integration architecture — how Salesforce talks to remaining on-prem systems (ERP, billing, etc.).
- Data migration plan — what comes, what gets archived, what gets dropped.
- Custom-feature parity — for each on-prem custom feature, decide: replicate / replace with native / drop.
Phase 3: Phasing strategy
Often phased to reduce risk:
- Phase 1: Sales Cloud — sales reps move to Salesforce.
- Phase 2: Service Cloud — service team migrates.
- Phase 3: Field Service / industry-specific.
During phasing, both systems coexist. Master data in one (typically Salesforce as new SoT). Sync maintains consistency.
Phase 4: Build
Salesforce build per phase. Sandboxes, DX, CI/CD established.
Phase 5: Data migration
- Profile legacy data.
- Cleanse — typical legacy data is messy.
- Map — every legacy field to Salesforce destination.
- Transform — formatting, defaulting, lookups.
- Migrate — Bulk API. Iterative passes.
- Validate — reconciliation reports.
Phase 6: Transition
- Train users thoroughly. Many have used legacy for 10+ years; the change is significant.
- Cutover plan — when does old system retire? Often months of parallel running before decommission.
- Hypercare for adoption.
Phase 7: Decommission
- Old system retires — capture historical archive.
- Legacy infra costs eliminated.
- Hardware / vendor licensing freed.
Common pitfalls:
- Underestimating data migration — always 2-3x what you expect.
- Underestimating user resistance — 10-year users hate change.
- Building Salesforce to mirror old system exactly — replicates legacy bad design instead of leveraging Salesforce capabilities.
- Insufficient parallel-run time — too short, defects miss; too long, expensive and confusing.
- Pulling the plug on old system too early — historical data needed for years.
Senior consultant insight: cloud transition is 40% technology, 60% change management. The technology can be solved; the human transition is harder.
The biggest win: don't replicate legacy. Use the migration as a chance to redesign processes that grew organically over years. Otherwise you spend millions to replicate complexity.