Migrating from a legacy CRM or vanilla Salesforce to Financial Services Cloud is the largest project most banks run on Salesforce. The technical work spans data mapping, integration rework, role and permission redesign, business-process reconfiguration, and user retraining. The calendar typically runs 9 to 18 months. The cost is in the hundreds of thousands to low millions of dollars. The risk is mostly in the data: customers whose records do not migrate cleanly become customers the bank cannot serve.
The data mapping decides the data quality. The cutover plan decides whether the project ships. Both deserve careful design before any code gets written.
What gets migrated
A typical bank running CRM migration to FSC moves data across several object families:
Customer master. The records that represent individual customers and businesses. Legacy systems often hold these as a single Customer object; FSC splits them into Person Account (individuals) and Business Account (companies).
Account relationships. The connections between customers (spouses, parents, business partners). Legacy systems often hold these as text fields or simple lookups. FSC has structured Account-Account Relationship and Account-Contact Relationship junctions.
Household and family structures. Legacy systems often have informal household grouping (a shared family ID, an implicit "household" through shared address). FSC has the explicit Household object.
Financial product holdings. The accounts, loans, policies, and investments each customer holds. Legacy systems may hold these in the CRM, in the core banking system, or both. FSC has the Financial Account object and its Record Types.
Relationships between people and financial products. The role each person plays on each account (Primary Owner, Joint Owner, Beneficiary, Trustee). Legacy systems often hold only the Primary Owner. FSC has Financial Account Role.
Customer interaction history. Calls, meetings, emails, documents. The legacy activity log gets migrated to the standard Activity surface.
Compliance and KYC records. Customer Risk Ratings, KYC status, screening results. Legacy systems vary widely; FSC has standard fields and standard objects.
Each family has its own mapping challenges, its own data-quality issues, and its own integration touchpoints.
The mapping pitfalls
Five mapping pitfalls Sapota has seen repeatedly:
Business Account versus Person Account split. Legacy systems often store individual customers as Business Accounts with the individual's name as the company name. The migration must split these into Person Accounts with appropriate Person fields populated. Detecting which legacy records are individuals versus companies is non-trivial. The detection logic needs business rules (no Business Tax ID, no employees, no Annual Revenue) plus manual review of edge cases.
Joint owner reconstruction. Legacy systems may store only the Primary Owner of a joint account. The Joint Owner data may live in a separate table, in a related document, or only in the core banking system. The migration needs to reconstruct the Joint Owner role records by joining across data sources. Missing this step produces accounts in FSC that look single-owner but are not.
Beneficiary and trustee data. Beneficiaries and trustees often live in unstructured form: notes, scanned documents, separate legal-instrument databases. The migration to FSC's Financial Account Role records requires extracting this data into structured form. The extraction is often the most expensive single step of the migration.
Address and contact data quality. Legacy systems accumulate years of address-data drift: misspellings, format inconsistencies, outdated information. The migration is an opportunity to clean this data. Skipping the cleaning step migrates the dirty data into FSC and locks the bank into a multi-year cleanup.
Implicit-household reconstruction. Many legacy systems have no explicit Household concept. The migration to FSC needs to infer households from shared addresses, shared surnames, account relationships, and any other available signals. The inference is imperfect; an explicit human-review step validates the inferences before they land in production.
Parallel-run patterns
A direct cutover from legacy to FSC on a single weekend is rarely the right answer. The legacy system typically has years of business logic, integrations, and workarounds that take time to identify and reproduce. A parallel-run period catches the gaps before the legacy system gets decommissioned.
Two parallel-run patterns work in practice:
Read-only legacy. The legacy system continues to receive data updates but no longer originates them. All new transactions and customer changes go through FSC. The legacy system serves as a fallback view and a comparison source. Typical duration: 3 to 6 months.
Selective parallel. Specific lines of business cut over to FSC while others remain on legacy. The wealth-management book moves first; retail banking follows 3 to 6 months later; commercial banking follows another quarter after that. Lower risk per cutover, longer total program duration.
The right pattern depends on the line-of-business risk profile and the integration complexity. Banks with highly-integrated legacy systems (heavy core banking integration, deeply embedded marketing automation) lean toward selective parallel. Banks with looser legacy integration lean toward read-only legacy.
Cutover sequencing
The cutover weekend has a defined sequence:
Friday afternoon: legacy freeze. The legacy system stops accepting new transactions and customer changes. Existing in-flight transactions complete; new ones queue.
Friday evening: data export. A final export from the legacy system captures the freeze-point data state. The export feeds the migration pipeline.
Saturday morning: migration run. The migration pipeline transforms the legacy data into FSC shape and loads it. The pipeline has been rehearsed multiple times against staging environments; the production run should be no-surprise.
Saturday afternoon: validation. A defined validation suite checks data integrity, record counts, key calculations, and integration health. Any discrepancies trigger investigation; resolved discrepancies trigger documented updates.
Sunday: user acceptance. Power users from the business log in to FSC and walk through real workflows against the migrated data. Issues found here are fixed before the wider user base comes online.
Sunday evening: integration cutover. The integrations that fed the legacy system get switched to FSC. Some integrations run in parallel for several weeks; some switch immediately.
Monday morning: go-live. The bank starts the week on FSC. The legacy system goes to read-only. A war-room operates for the first 1 to 2 weeks to handle issues.
Each step has owners, deadlines, rollback criteria, and a defined escalation path. The cutover document runs to dozens of pages. Rehearsal cycles tighten the script over weeks of preparation.
The validation suite
The post-migration validation suite is the safety net. Three categories of validation matter:
Record-count reconciliation. Total customer count, account count, relationship count, transaction count must match between legacy and FSC (within an explainable variance). Mismatches indicate either lost records or duplicated records.
Calculation reconciliation. Total assets, total deposits, total loans, net worth across the customer base must match between legacy and FSC. Mismatches indicate either lost values or transformation errors.
Spot-check reconciliation. A sample of complex customer cases (multi-member households, complex trusts, large books) gets walked through manually. The manual walk-through catches subtle errors that aggregate reconciliations miss.
The validation suite gets rehearsed in staging and runs against production immediately post-migration. Any failure that cannot be resolved triggers either a roll-back (rare and expensive) or a documented exception list for follow-up resolution.
Integration rework
The migration affects more than the data. Every system that talked to the legacy CRM now needs to talk to FSC. The integration rework is often half the migration project's effort.
The integrations that need rework typically include:
- Core banking system (bidirectional account data sync).
- Marketing automation (customer segmentation and campaign execution).
- AML system (customer context for transaction monitoring).
- Document management (file storage and retrieval).
- Reporting and BI (dashboards and regulatory reports).
Each integration has a planning phase, a build phase, a testing phase, and a cutover phase. The integrations often follow the same cutover weekend as the core data migration, which makes the weekend long and intense.
Post-cutover optimisation
The week or two after cutover is the most important period for ongoing FSC success. Two patterns matter:
Active issue management. Every issue surfaced by users gets logged, triaged, and resolved with documented turnaround. The war-room model keeps response times short.
Performance tuning. Production load reveals performance issues that staging did not. SOQL queries that ran fine against 10K records may struggle against the full 10M records. The optimisation work happens in the first weeks; delaying it lets users develop workarounds that are hard to dislodge later.
Banks that nail post-cutover see FSC adoption stick. Banks that under-resource post-cutover see users revert to spreadsheets and side systems within months.
Planning a migration from a legacy CRM or vanilla Salesforce to FSC? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs migration architecture, data-mapping design, and cutover execution on every FSC migration engagement. Get in touch ->
See our Salesforce service page for the team.
