How to Migrate from 360view CRM to Salesforce FSC

A 360view to Salesforce FSC migration is a schema translation project, not a lift-and-shift. The hard part is not pulling rows out of 360view. The hard part is converting a banking-native model built around households, multi-party product ownership, referrals, profitability, and core-fed account context into FSC's person, household, relationship, and financial-account structures without breaking ownership logic or auditability.

If you already know you are moving to FSC, the safest default is this: choose the FSC household and person model first, migrate only the data that is truly mastered in 360view, and re-sync core-sourced balances and product facts from Fiserv, Jack Henry, FIS, or another core processor into Salesforce directly. The CRM load does not recreate 360view's core integration layer for you.

This guide covers object mapping, viable migration methods, banking-specific planning steps, load order, and the edge cases that silently destroy data integrity. If you are a CTO or implementation lead at a community bank or credit union that has committed to FSC, this is the technical scope document you need before you budget or staff the project.

Why 360view to Salesforce FSC Migration Is Harder Than a Generic CRM Move

Three things make this specific migration path uniquely difficult.

1. Two banking-native models that disagree on structure. 360view was built for banks and credit unions — designed for the financial industry from the ground up by experienced bankers, 360 View goes beyond CRM. Its data model treats households as the primary entity, with contacts, product holdings, profitability scores, and referral chains hanging off the household. Salesforce FSC also models financial relationships, but unlike general customer relationship management systems, the Financial Services Cloud uses a model that reflects how people, households, and businesses interact with financial products. The structural mismatch means you cannot just export-import — you need to reshape every record.

2. The Person Account decision is irreversible. The Person Account model is the preferred model for FSC and is enabled and setup as the default data model for all new FSC orgs. Once Person Accounts are enabled, they cannot be disabled. This decision must be locked in before a single record is loaded, and it fundamentally changes how contacts, households, and financial accounts relate to each other.

3. Core banking data complicates scope. 360 View is designed from the ground up to connect seamlessly with over 15 core banking platforms such as Jack Henry, Fiserv, FIS, and Corelation. Much of what lives in 360view — balances, product details, transaction history — is actually a synced copy of core banking data. Post-migration, Salesforce FSC needs its own core integration, and you need to decide: migrate the core-synced data, or re-sync it from core directly into Salesforce? The answer determines half your migration scope.

Regulatory stakes are high. Partial migrations or lost data can create gaps in CRA (Community Reinvestment Act) reporting, BSA/AML audit trails, and customer communication records. The FFIEC BSA/AML manual documents recordkeeping requirements for customer accounts and records that support a bank's compliance program. If 360view notes, referrals, relationship assignments, or household structures feed audit, outreach, or reporting workflows, a partial migration can create control gaps even if frontline users think the new screens look fine. For a broader risk list, see 7 Costly Mistakes to Avoid When Migrating Financial Data.

Choose the FSC Data Model Before You Map Anything

Two architectural decisions must be finalized before you write a single line of transform code. Get either one wrong and you are rebuilding the entire pipeline.

Household Model

In current FSC, there are two native household patterns worth considering:

• Managed-package Household Account pattern: Represents a household as an Account with the Household record type. Householding is meant to group Person Accounts/Individuals together under a single umbrella Account called a Household. The connection between the Person Account and the Household Account is maintained via the Account-Contact Relationship (ACR) object, which serves as a junction object and includes additional settings such as a defined Role, Start Date, End Date, and how rollups to the Household should behave.

• Standard Groups and Households: Represents a household through a combination of Account plus Party Relationship Group. This aligns with newer standard FSC object families and reduces managed-package dependency over time.

Use the managed-package pattern if your implementation already depends on legacy FSC packaged behavior, household rollups, or related packaged UX. Use standard Groups and Households if you want to align to the newer standard FSC direction. A fully custom Household object is possible, but it should be the exception. Once you walk away from native FSC household behavior, you own more rollups, more security logic, more relationship UX, and more migration code.

In 360view, the household is the primary entity. In either FSC pattern, the household is a container, not the root entity. Each FSC person can have only one primary group for rollup purposes, and group rollup summary data is reflected only for the primary group. If your 360view instance contains merged, split, or historically changing households, you need an explicit rule for current-state versus historical-state migration.

Person Accounts vs. Contacts

Person Accounts combine account and contact fields into a single B2C record experience. Person accounts store information about a person by combining certain account and contact fields into a single object experience. Salesforce says the older individual model (standard Contacts) is supported only for FSC orgs with existing individual-model implementations. For a new community bank or credit union FSC build, Person Accounts are the default answer.

The trade-off is permanence. Salesforce states that Person Accounts cannot be disabled after enablement, and enabling them also changes your available organization-wide default sharing options for Account and Contact. Make this decision before you finalize reporting, integrations, user training, or any transform code.

If you deliberately stay on a standard Contact model, confirm Contacts to Multiple Accounts early. Salesforce uses Account Contact Relationship records for multiple-account relationships and group membership, and some orgs still require support involvement to enable the feature. That is a setup dependency, not a nice-to-have.

360view to Salesforce FSC: Core Object Mapping

The right way to think about this migration is object by object, then relationship by relationship. The table below maps every major 360view concept to its FSC equivalent. "Clean" means the mapping is straightforward. "Transform" means structural reshaping is required. "Rebuild" means no equivalent exists.

Detailed Field Mapping Worksheet

The overview table above shows the conceptual mapping. The worksheet below goes field-by-field for the core objects. Treat this as a starting template — finalize the exact source column names and target API names against your own 360view instance and FSC sandbox, since both systems support customization. Some FSC objects can share the same label while existing as either standard or managed-package objects, so validate literal API names in your environment before development.

Relationship Preservation and Load Order

The hierarchy you need to preserve is: Household → Individual/Business → Product Holding → Activity/Referral/File. In FSC, that hierarchy is not stored as one nested document. It is stored through parent records plus junction objects: Account-Contact Relationship for group membership, and Financial Account Role or Financial Account Party for product ownership.

Every record needs an External ID — a unique identifier from 360view — to enable upsert operations and parent-child linking during load. A practical external-ID design:

• LegacyHouseholdKey__c on household or group accounts
• LegacyPersonKey__c on Person Accounts or Contacts
• LegacyBusinessKey__c on Business Accounts
• LegacyFinancialAccountKey__c on Financial Accounts
• LegacyReferralKey__c on Leads or custom Referral objects
• LegacyOpportunityKey__c on Opportunities
• LegacyActivityKey__c on Tasks and Events
• LegacyFileKey__c on ContentVersion

If you plan to land migrated CRM data and core data in Data Cloud later, consider a fully qualified key scheme now so those sources do not collide downstream. Salesforce explicitly recommends fully qualified keys when ingesting data from more than one source into Data Cloud.

Load in this order:

1.  Reference data: record types, picklists, queues, users, branch records, territories, permission sets
2.  Household Accounts (or Group Accounts + Party Relationship Group records)
3.  Person Accounts (or Contacts)
4.  Business Accounts
5.  Account-Contact Relationship rows
6.  Financial Accounts
7.  Financial Account Role / Party rows (Primary, Joint, Signer, Beneficiary, Guarantor)
8.  Referral Leads and Opportunities
9.  Tasks, Events, Notes
10. Files (ContentVersion + ContentDocumentLink)

Load order matters. You cannot load Financial Accounts before the owning Person Accounts exist. You cannot create ACR records before both the Household Account and the Person Account exist. Violating this order causes orphaned records.

Two technical constraints to plan around:

• Primary Owner requirement: Each Financial Account must have at least one active Primary Owner role, or data-loading errors will occur. Your transform code should validate this before generating load files.
• Polymorphic lookup limitation: Data Loader cannot use external IDs on polymorphic fields like WhatId on Tasks and Events. Resolve those lookups to real Salesforce IDs in your transform layer, or use a loader that supports the mapping pattern you need.

4 Approaches to Execute the 360view Migration

The right approach depends on household count, relational complexity, hosting model, and whether anyone on your team wants to own the transform and validation code.

A. Manual CSV Export + Data Loader

Extract data from 360view's native reporting tools (360view advertises more than 150 standard reports and a report writer) or request structured exports from the 360view team. Transform CSVs to match FSC schema. Load via Salesforce Data Loader or Dataloader.io.

When to use: Small institutions with under 5,000 households and simple data structures.

Limitations: Flat CSV reports strip household and product relationship context. Every parent-child link must be manually mapped with External IDs. Error-prone at scale. Free Dataloader.io is capped at 10,000 rows per month, so it stops being viable quickly on a real banking dataset. For details on why flat exports lose relational context, see Using CSVs for SaaS Data Migrations.

B. API-Based Custom Migration

With 360 View API, you can query main CRM objects (customers, accounts, referrals, incidents, pipelines, activities) and add/update any of those objects. The 360 View uses the OAuth 2.0 protocol for authorization. Access to this form requires a 360 View API focus plan which has to be added to your 360 View installation by our support department.

This is not like migrating from HubSpot or Salesforce where APIs are fully documented and open. 360view's API requires a paid license, has throttling limits to protect the core application, and uses pageSize and pageNo in the URL query string to paginate. For a deeper dive on extraction limits, see How to Export All Data from 360 View CRM: Methods & Limits (2026).

Extract via 360view REST API → Transform in Python/Node.js → Load via Salesforce Bulk API 2.0.

When to use: Dedicated engineering team, large datasets, complex transformations, and expectation of multiple dress rehearsals.

C. Database-Level Extract + ETL Pipeline

For institutions that can obtain a SQL Server database dump from 360view — or now Abrigo, since Abrigo has acquired 360 View — build transformation logic in SQL/Python to reshape relational data into FSC's object model. Load via Salesforce Bulk API 2.0. You can process up to 100 million records per 24-hour period using Bulk API 2.0. You can upload up to 150 MB of data per job.

This is the most common approach for large 360view migrations because the API is throttled and may not expose all data objects at the granularity needed. FI-hosted deployments can expose a Microsoft SQL Server back end. The advantage is full relational extraction without API pagination. The downside is that direct SQL access is not publicly documented as a supported vendor extraction interface, so you need read-only discipline and vendor awareness.

When to use: Large institutions with complex data, FI-hosted 360view, and engineering resources. If you can get database access early, pursue it in week one — it is often the real project bottleneck.

D. Managed Migration Service

Partnering with a team that specializes in financial CRM migrations to handle extraction coordination with 360view/Abrigo, transformation logic, relationship preservation, validation evidence, and rollback support.

When to use: Most community banks and credit unions — limited IT staff, compliance requirements, no appetite for building custom ETL. The real work is not just export plus import. It is source coordination, transform logic, audit-field handling, load sequencing, branch-level UAT, and rollback planning. A managed service absorbs those tasks and owns the middle.

For a broader framework on CRM migration approaches, see Best Practices for CRM Data Migration in 2026: The Engineer's Guide.

Pre-Migration Planning for Financial Institutions

This is banking-specific, not generic CRM advice. Complete these steps before moving a single record.

1. Data audit. Count households, people, business entities, product holdings, financial-account-role equivalents, referrals, opportunities, activities, incidents, documents, and custom fields. Get exact record counts per object. You need these numbers to estimate Salesforce storage costs and Bulk API load times. If you do not know those counts by object, you are not estimating a migration yet — you are guessing.

2. Separate core-synced data from 360view-native data. Data that is a copy of core banking data (balances, product details, transaction history) should not be migrated from 360view. Set up a new core-to-Salesforce integration and let it repopulate. Only migrate 360view-native data: notes, activities, referrals, relationship assignments, custom fields, and profitability scores. For extraction strategies, see How to Export All Data from 360 View CRM: Methods & Limits (2026).

3. Define historical scope. Do you migrate all historical data or only active households? For CRA and BSA/AML compliance, you likely need complete history. For operational use, you may choose a cutoff date. Make the cutoff rule object-specific: active households plus all open product holdings, all referrals for the last seven years, all notes for active and recently closed relationships, and archived extracts for anything not loaded into Salesforce.

4. Regulatory checklist. Ask directly:

• Does any 360view data feed CRA reporting, branch performance review, or public-file workflows?
• Do relationship managers rely on historical communication notes for complaint handling or audit response?
• Do BSA or AML review processes reference CRM relationship or ownership context?
• Do you need original created dates, last modified dates, and legacy owners preserved?

Salesforce can preserve audit fields (CreatedDate, LastModifiedDate) during insert with the right permissions, but cannot import Field History Tracking records. If you need pre-Salesforce change history for audit or regulator response, archive it outside standard field history or store it in a separate immutable structure.

5. Configure FSC before migration. The FSC data model must be set up before any data lands: Person Account enablement, household model selection, Financial Account record types, custom fields, picklist values, page layouts, permission sets, territory management, and sharing rules. This is typically a 4–8 week workstream on its own. Before your first full load, understand your target-side backup and validation options with How to Export Data from Salesforce Financial Services Cloud.

6. Choose a rollout strategy. Phased by branch, by customer segment, or big bang. For community FIs, phased by branch is usually safest — it limits blast radius, gives branch managers ownership of validation, and lets you correct household and product-role edge cases before loading the full institution.

The 8-Step Technical Migration Process

Phase 1: Extract from 360view

Coordinate with the 360view/Abrigo team early. Your extract path may be reports, API, vendor-generated structured files, or direct SQL for FI-hosted deployments. Whatever the path, verify completeness against your pre-migration audit before you write transform logic. If the API only covers some objects, document the gaps immediately.

Getting database-level access from 360view/Abrigo is often the project bottleneck. Start that conversation in week one.

Phase 2: Profile and clean the source data

Find duplicates, orphaned product holdings, invalid user references, dead branch codes, missing household anchors, incomplete households, stale referral assignees, and activity rows that point to records you are not migrating. Banking data looks relationally complete until you test household-to-product and product-to-owner joins at scale.

Separate core-synced data from 360view-native data during this phase. Only transform data that belongs in Salesforce.

Phase 3: Transform into the FSC schema

This is where most of the real work lives. Normalize picklists. Split one 360view product row into a Financial Account plus one or more ownership rows. Convert household membership into ACR records. Generate external IDs. Resolve whether balances are being migrated or re-synced.

Here is a transform structure demonstrating how to reshape 360view data into FSC's object model:

mode = 'person_accounts'  # or 'contact_model'
 
for hh in households:
    hh_key = f'HH:{hh.id}'
    emit_household(
        ext_id=hh_key,
        name=build_household_name(hh),
        branch=map_branch(hh.branch_code),
        profitability=hh.profitability_score
    )
 
    for member in members_by_household[hh.id]:
        person_key = f'P:{member.customer_id}'
        emit_person_or_contact(
            ext_id=person_key,
            first_name=member.first_name,
            last_name=member.last_name,
            email=normalize_email(member.email),
            owner=map_user(member.assigned_banker)
        )
        emit_household_membership(
            household_ext_id=hh_key,
            person_ext_id=person_key,
            roles=map_household_role(member.role),
            start_date=member.start_date,
            end_date=member.end_date,
            is_primary=member.is_primary_group
        )
 
for product in product_holdings:
    fa_key = f'FA:{product.product_id}'
    emit_financial_account(
        ext_id=fa_key,
        record_type=map_financial_account_type(product.product_type),
        name=build_product_name(product),
        core_account_id=product.core_account_id,
        open_date=product.open_date,
        balance=maybe_keep_balance(product)
    )
 
    owners = parties_by_product[product.product_id]
    primary_seen = False
    for owner in owners:
        role = map_financial_role(owner.role)
        if role == 'Primary Owner':
            primary_seen = True
        emit_financial_account_role(
            financial_account_ext_id=fa_key,
            person_ext_id=f'P:{owner.customer_id}',
            role=role
        )
 
    if not primary_seen:
        raise ValidationError(f'Missing primary owner for {fa_key}')

Note the primary-owner validation at the end of each product. FSC requires at least one active Primary Owner per Financial Account. Catching this in your transform code prevents silent load failures.

Phase 4: Prepare Salesforce FSC

Create all custom fields, record types, picklists, permission sets, sharing rules, and household/group configuration before load day. Enable audit-field permissions only for the migration users that need them. If you are loading at volume, review FSC rollup behavior — Salesforce documents rollup and rollup-by-lookup considerations that affect data-load performance.

Ensure your Salesforce FSC export and backup mechanisms are in place before loading production data.

Phase 5: Pilot load

Load one branch or a sample of 200–500 households. Do not pilot with a clean demo subset. Pilot with real complexity: joint owners, business households, mixed deposit and loan holdings, old referrals, attachments, and messy household histories.

Validate end-to-end: Household → Person Accounts → ACR roles → Financial Accounts → Financial Account Roles → Activities → Documents. Have the branch manager review real customer records. This is the only validation that catches "technically correct but operationally wrong" errors.

Phase 6: Full migration

Run the full load only after the pilot passes. Load in the dependency order described above. Use Bulk API 2.0 for volume. Monitor for failures per batch.

For large credit unions with 100K+ households and millions of product holding records, plan load windows carefully. Salesforce Bulk API allows up to 15,000 batch submissions per 24 hours, shared between Bulk API 1.0 and 2.0. Each batch can contain maximum 10,000 records with a 10MB payload limit. A million-record Financial Account load may take multiple days.

Phase 7: Validation and UAT

Run these checks before declaring the migration complete:

• Record count reconciliation by object type and by branch — totals must match between 360view source and Salesforce target
• Household completeness — every migrated household has all expected Person Accounts, Financial Accounts, and activities
• ACR role accuracy — Primary, Joint, Authorized Signer roles match source assignments
• Financial Account data — product types, open dates, masked account numbers, and balance strategy match source
• Activity history — no missing notes, calls, or meeting records
• Document verification — spot check that files are linked to correct records and are accessible
• CRA data validation — if 360view was used for CRA reporting, run parallel reports in both systems to confirm all reportable data is present and correctly categorized
• UAT by branch managers using real customer records — the only validation that catches operationally wrong data

Phase 8: Core banking integration cutover

Only after the CRM data passes validation should you switch the core feed from 360view to Salesforce. Treat this as a separate cutover checklist with its own rollback criteria, monitoring, and sign-off. Switch off the 360view-core sync and activate the Salesforce-core sync. Validate that data flows correctly before decommissioning 360view.

Edge Cases That Break 360view to FSC Migrations

Joint account holders and signer logic

360view commonly links multiple contacts to a single product holding. In FSC, use one Financial Account row per product and one Financial Account Role (managed-package) or Financial Account Party (standard) row per involvement type: Primary Owner, Joint Owner, Authorized Signer, Beneficiary, Guarantor, Trustee. Do not duplicate the Financial Account record to represent multiple owners. If your transformation does not explicitly map these roles, FSC will not know who owns what.

Household merges and splits

If households were merged or split in 360view's history, decide whether to migrate current state only or preserve historical household compositions. Most institutions migrate current state and archive the history. FSC's ACR records support start and end dates, making them the right place to preserve composition changes if you choose to load historical relationships. Remember that FSC primary-group rollups only reflect one primary group per person, so overlapping household history needs a clear archival or custom reporting strategy.

Profitability does not migrate as logic

Profitability data within your CRM gives you a clear picture of the value of individual customers to your business. Household relationship information highlights the revenue one customer brings across all of his or her accounts. 360view calculates profitability at the household level using core data. Salesforce FSC does not have native profitability scoring. The calculation logic does not migrate — only the historical scores can be mapped to custom fields on the Account or Financial Account. To have live profitability post-migration, rebuild the logic in CRM Analytics (Tableau CRM), Data Cloud, or an external analytics layer.

Referral chains are not a one-to-one match

360view tracks referral source, recipient, and product outcome as linked objects — including automated referral closing on new account opening. In FSC, referrals typically live on the Lead object with a Referral record type and may feed Opportunities later. If you need employee-to-employee routing, service-level timers, product outcome tracking, or branch-level referral-credit attribution, add explicit custom fields or a custom referral object rather than pretending Lead alone is enough. Note that Salesforce documents lead conversion is not supported for Group record types (including Household), so do not base your conversion logic on the household record.

Alerts and SmartPops must be rebuilt

360view's alert system — balance thresholds, maturity date triggers, life event notifications, SmartPops — has zero equivalent in Salesforce as a migratable object. Every alert must be rebuilt as a record-triggered Flow, scheduled Flow, or Apex job that evaluates conditions against the new data model.

Branch-level data segmentation is a security project

360view segments data by branch natively. In Salesforce, branch visibility is controlled through Territory Management and sharing rules. This security model must be designed and implemented before migration, not after. If you postpone this, UAT results are unreliable because users validate through the wrong visibility rules, and tellers may see records from branches they should not access.

Files are their own workstream

Documents, scanned correspondence, KYC files, and attached notes should be handled separately from core row data. Salesforce Files are stored through ContentVersion, ContentDocument, and ContentDocumentLink. Using FirstPublishLocationId during ContentVersion insert simplifies initial record linking. Plan file migration as a distinct workstream with its own validation — spot-check that KYC documents and correspondence are linked to the correct Person Account.

Data volume changes the tooling decision

Data Loader is supported for loads up to 5 million records. Once you approach that threshold, or if your rollups are heavy, plan on Bulk API 2.0 plus chunking by object, branch, or cohort. Large credit unions with millions of product holding records should plan multi-day load windows and carefully sequence rollup-triggering operations.

Post-Migration: Core Sync, Analytics, and Decommissioning

The data migration is not the same project as the core banking integration cutover. If 360view was the CRM layer sitting on top of your core, FSC now becomes that layer.

Core banking integration. Set up the Salesforce-to-core integration (Fiserv, Jack Henry, FIS) to replace 360view's core sync. This workstream needs separate testing, monitoring, and rollback planning. Without it, financial account data goes stale immediately after migration.

Rebuild analytics. Profitability dashboards, cross-sell reports, branch performance metrics, and referral conversion reporting do not migrate from 360view. These must be rebuilt in Salesforce Reports and Dashboards or CRM Analytics. Treat them as new reporting products — do not assume data will look familiar on day one. If you are using Data Cloud for financial services, Salesforce explicitly recommends fully qualified keys when multiple sources feed the model. That matters once core data and migrated CRM history start meeting in the same analytics layer.

Rebuild workflows. Maturity alerts, balance threshold notifications, life event triggers, service follow-ups, referral escalations — all rebuilt as Salesforce Flows or Apex.

Train users. Relationship managers, tellers, and branch managers need training on FSC. The UX is fundamentally different from 360view. Budget 2–4 weeks for training and adoption support.

Plan a parallel run. Run both systems for 2–4 weeks before final decommission. This lets you confirm core feeds, branch validation, and day-to-day workflows are stable before losing the fallback. For the general case on parallel-running strategy, see Why Running Two CRMs in Parallel Beats a Hard Cutover.

Decommission 360view. Plan for contract termination, data retention obligations, and archival of 360view data for compliance. Financial regulators may require that you retain the original data for a defined period. Archive migration-ready exports, mapping documents, validation evidence, and a searchable archive of retired 360view history according to your institution's retention policy.

Decisions to Lock Down Before You Start

If you take nothing else from this guide, lock down these decisions first:

1. Which FSC household model are you using? Managed-package Household Account or standard Groups and Households?
2. Are you standardizing on Person Accounts or staying on a Contact model for a specific reason?
3. Which data is truly authored in 360view versus re-sourced from core?
4. Which FSC object family are you loading — standard, managed-package, or a deliberate hybrid with documented boundaries?
5. What evidence will prove data completeness to IT, operations, and compliance?

The institutions that execute this well get serious about extraction early, freeze the target FSC model before transform code starts, and refuse to blur system-of-record boundaries. The ones that struggle wait too long on one of those three decisions. 360view export paths are limited compared with more open CRMs, Person Accounts are irreversible once enabled, and FSC object families need to be chosen deliberately before loading millions of rows.

If your institution does not have spare engineering capacity to own extraction coordination, household-to-FSC transform logic, and regulator-ready validation evidence, that is the point where a managed migration service becomes rational rather than expensive.