The Vantage View | Salesforce

FSC Core vs. Managed Package: The Complete Migration Guide for 2026

Written by David Cockrum | Mar 13, 2026 11:59:59 AM

Salesforce FSC Core vs. Managed Package: The 2026 Migration Planning Guide

TL;DR / Key Takeaways

  • What is it? A comprehensive guide to understanding the differences between Salesforce FSC Core and the FSC Managed Package, and how to plan your migration
  • Key Benefit: FSC Core unlocks Agentforce AI agents, modern data architecture, improved performance, and all future Salesforce financial services innovation — the managed package will not receive these capabilities
  • Best For: RIAs, wealth management firms, banks, insurance companies, and any financial services organization currently on the FSC managed package evaluating a transition to FSC Core
  • Cost/Investment: Migration typically requires 6-16 weeks and $40,000-$150,000+ depending on customization complexity, integrations, and data volume
  • Bottom Line: Salesforce hasn't announced an end-of-life date for the managed package, but all future innovation — including Agentforce, Compliance Navigator, and advanced AI — is exclusive to FSC Core. The question isn't whether to migrate, but when.

The Fork in the Road

If your financial services firm runs Salesforce Financial Services Cloud, you're facing one of the most consequential technology decisions of 2026: stay on the FSC managed package or migrate to FSC Core.

Salesforce launched FSC in 2016 as a managed package — a pre-built set of objects, fields, and code installed as an add-on to the core Salesforce platform. It gave financial services firms an industry-specific data model for client management, householding, and financial account tracking without building everything from scratch.

Starting in 2019, Salesforce began rebuilding FSC natively on the core platform. That effort has accelerated dramatically, and the message from Salesforce is now unmistakable: FSC Core is the future. The managed package is not being abandoned — but it is being left behind by innovation.

Here's what that means in practical terms:

Capability FSC Managed Package FSC Core
Agentforce AI agents ❌ Not available ✅ Pre-built agents for meeting prep, follow-up
Compliance Navigator ❌ Not available ✅ Real-time compliance monitoring (roadmap)
Flexible Hierarchy Management ❌ Not available ✅ Multi-entity visualization (Spring '26)
Financial Account Balance History ❌ Single overwritable balance ✅ Full balance history records
Multi-owner Financial Accounts ❌ Primary/Joint Owner lookups ✅ Junction object for unlimited owners
Modern Household Model ❌ Account record types ✅ Party Relationship Groups
Summary & Record Rollups ❌ Rollup by Lookup Rules ✅ Configurable native rollups
Data Cloud Integration Limited ✅ Full native integration
Future Salesforce Releases Minimal updates ✅ All new features and innovation

If you're evaluating Agentforce, Data Cloud, or any advanced Salesforce capability for financial services — you need FSC Core. There is no alternative path.

Understanding the Key Architectural Differences

The shift from managed package to FSC Core isn't just a version upgrade — it's a fundamental change in how your financial services data is modeled and managed. Understanding these differences is essential for planning your migration.

Financial Account Ownership

Managed Package: Ownership is driven by two lookup fields — Primary Owner and Joint Owner. This is simple but limiting. A financial account can only have two owners, and one must be designated as primary.

FSC Core: Ownership uses a junction object called Financial Account Party. This creates a many-to-many relationship between Accounts (clients) and Financial Accounts, allowing: - Unlimited owners per financial account - Flexible role definitions (primary, joint, beneficiary, trustee, custodian) - No requirement to designate a single primary owner

Why this matters: In wealth management, ownership structures are rarely as simple as one or two people. Trusts, partnerships, corporate accounts, and multi-generational family structures require flexibility that the managed package can't provide.

Financial Account Balances

Managed Package: A single balance field on the Financial Account object. When a balance is updated (manually or via integration), the previous balance is overwritten. No history.

FSC Core: Balances are stored as records in a Financial Account Balance child object. Each update creates a new record, maintaining a complete history of account balances over time.

Why this matters: Balance history is essential for performance reporting, trend analysis, and compliance documentation. It also eliminates the Apex trigger performance issues that plague managed package environments during nightly custodial data loads.

Household Management

Managed Package: Households are modeled using Account record types — a Business Account record type represents the household, with individual Contact records associated to it.

FSC Core: Households use a two-object model: 1. Business Account — functions like any standard Salesforce account 2. Party Relationship Group — defines the Business Account as a Household and stores household-specific information

Party Relationship Groups support: - Multiple relationship types within a household - Cross-household relationships - Group-level rollups and analytics - A setup wizard for creating new households

Why this matters: The Party Relationship Group model is more flexible and extensible than the record type approach. It supports complex family structures, multi-generational households, and entity relationships that are common in wealth management and private banking.

Relationship Mapping

Managed Package: Uses a Relationship Map component that visualizes connections between accounts and contacts.

FSC Core: Replaces the Relationship Map with the Actionable Relationship Center (ARC) — a more powerful visualization tool that allows users to: - View hierarchical and lateral relationships - Take actions directly from the relationship map (create tasks, send emails, update records) - Configure relationship types and display rules - Model complex multi-entity structures

Rollup Architecture

Managed Package: Uses Rollup by Lookup Rules with Apex triggers. This approach has known performance limitations, especially during high-volume data loads from custodial integrations. Nightly batch updates can cause trigger conflicts and processing delays.

FSC Core: Uses configurable Record Rollups and Summary Rollups built natively into the platform: - Record Rollups aggregate related records (e.g., all cases for household members) without Apex triggers - Summary Rollups aggregate financial account balances using the Financial Account Summary object - No Apex trigger dependencies means better performance during data loads - Real-time rollup options available

Why this matters: If your firm has ever experienced slow nightly data loads, trigger conflicts, or stale rollup data, FSC Core's native rollup architecture directly addresses these pain points.

The Migration Planning Framework

Migrating from the FSC managed package to FSC Core is a significant but manageable project. The key is thorough planning, methodical execution, and testing at every stage.

Step 1: Assess Your Current State (1-2 Weeks)

Before touching any configuration, document your current environment:

Data Model Inventory: - Which managed package objects are you using? (Financial Account, Financial Account Role, etc.) - What custom fields have you added to managed package objects? - Are you using custom objects for financial services data? - How are households currently structured?

Integration Map: - Which custodial feeds update financial accounts? (Schwab, Fidelity, Pershing, etc.) - What third-party AppExchange packages depend on managed package objects? - How do portfolio management integrations (Orion, Black Diamond) interact with your data model? - Are financial planning tools (MoneyGuidePro, eMoney) integrated?

Customization Audit: - Custom Apex triggers on managed package objects - Workflow rules and Process Builder flows that reference managed package fields - Reports and dashboards built on managed package data - Lightning pages and components that use managed package components

ISV Dependency Check: This is critical. Some third-party AppExchange packages may depend on managed package objects. Verify with each vendor whether they support FSC Core's standard objects. If they don't yet, you may need to plan your migration timeline around their roadmap.

Step 2: Design the Target State (1-2 Weeks)

Map your current configuration to the FSC Core equivalent:

Managed Package Element FSC Core Equivalent
Financial Account (managed package) Financial Account (standard object)
Primary Owner / Joint Owner lookups Financial Account Party junction object
Balance field on Financial Account Financial Account Balance child records
Account record type: Household Business Account + Party Relationship Group
Rollup by Lookup Rules Record Rollups + Summary Rollups
Relationship Map Actionable Relationship Center (ARC)
Custom fields on managed package objects Recreate on standard objects
Record types on managed package objects Recreate on standard objects

Salesforce provides detailed field mapping documentation: - Financial Account metadata mapping - Groups and Households mapping

Step 3: Configure FSC Core in a Sandbox (2-4 Weeks)

Important: FSC Core can coexist with the managed package. You don't have to rip out the managed package before building FSC Core objects. This allows for a phased migration.

Configuration steps: 1. Enable Financial Account Management Standard Objects in Setup 2. Recreate custom fields on standard objects (map from managed package equivalents) 3. Configure Financial Account Party relationships for multi-owner modeling 4. Set up Party Relationship Groups for household management 5. Configure Record Rollups and Summary Rollups to replace Rollup by Lookup Rules 6. Set up the Actionable Relationship Center to replace the Relationship Map 7. Recreate Lightning pages using standard object components 8. Update automations (Flows, triggers, Process Builder) to reference standard objects 9. Rebuild reports and dashboards on standard objects

Step 4: Migrate Data (1-3 Weeks)

Data migration is typically the most complex phase:

  1. Financial Accounts — Migrate records from managed package Financial Account to standard Financial Account
  2. Ownership — Convert Primary Owner/Joint Owner data to Financial Account Party records
  3. Balances — If you have historical balance data elsewhere, create Financial Account Balance records
  4. Households — Convert household Account records to Business Account + Party Relationship Group pairs
  5. Relationships — Migrate relationship data to the new model
  6. Custom data — Migrate any custom field data from managed package objects to standard object equivalents

Pro tip: Run the migration in a sandbox first. Validate record counts, field mapping accuracy, and relationship integrity before touching production. We typically run 2-3 migration cycles in sandbox before the final production migration.

Step 5: Update Integrations (1-3 Weeks)

This is where ISV dependencies become critical:

  • Custodial data feeds — Update field mappings to target standard Financial Account objects and Financial Account Balance records
  • Portfolio management integrations — Verify Orion, Black Diamond, or Tamarac connectors support standard objects
  • Financial planning integrations — Update MoneyGuidePro, eMoney, or RightCapital connections
  • AppExchange packages — Verify compatibility with FSC Core, update configurations, or find alternatives
  • Custom integrations — Update API calls, field references, and data mapping

Step 6: Test Comprehensively (1-2 Weeks)

  • Data accuracy — Verify migrated records match source data
  • Integration testing — Run custodial data loads and verify correct object/field targeting
  • Workflow testing — Validate all automations fire correctly on standard objects
  • User acceptance — Have advisors, operations, and compliance teams validate the experience
  • Performance testing — Verify rollup performance during simulated data loads
  • Reporting — Confirm all reports and dashboards produce accurate results

Step 7: Go-Live and Transition (1-2 Weeks)

  • Final production migration with a defined cutover window (typically a weekend)
  • Parallel verification — Advisors verify key client records and relationships
  • Decommission managed package references — Redirect users to standard object pages and components
  • Training — Focused sessions on new interfaces (ARC, new household model, agent capabilities)
  • Post-go-live support — 2-4 weeks of intensive monitoring and rapid issue resolution

Common Migration Pitfalls (And How to Avoid Them)

Pitfall 1: Skipping the ISV Dependency Check

Risk: You migrate to FSC Core, and a critical AppExchange package breaks because it depends on managed package objects. Solution: Inventory every third-party package. Contact each vendor. Get written confirmation of FSC Core support before migrating.

Pitfall 2: Underestimating Custom Field Migration

Risk: You have dozens (or hundreds) of custom fields on managed package objects that need to be recreated. Solution: Generate a complete field inventory early. Map every field, including field type, picklist values, validation rules, and dependencies.

Pitfall 3: Mixing Managed Package and Standard Objects

Risk: During a phased migration, some data lives in managed package objects and some in standard objects, creating inconsistencies and reporting gaps. Solution: Define clear boundaries. Migrate by entity type (all financial accounts at once, all households at once) rather than incrementally.

Pitfall 4: Forgetting About Reports and Dashboards

Risk: Leadership dashboards and compliance reports break because they reference managed package objects. Solution: Inventory all reports and dashboards early. Rebuild them on standard objects in the sandbox and validate before go-live.

Pitfall 5: Not Planning for Rollup Recalculation

Risk: After migration, rollup data is stale or incorrect because the new rollup engine hasn't processed historical data. Solution: Plan for a full rollup recalculation after data migration. Budget time for the processing to complete.

Should You Migrate Now or Wait?

This is the question every financial services firm on the managed package is asking. Here's our framework:

Migrate Now If:

  • You want to deploy Agentforce AI capabilities
  • You're experiencing performance issues with nightly data loads and trigger conflicts
  • You're planning a broader Salesforce modernization (Data Cloud, MuleSoft, Einstein Analytics)
  • Your ISV partners already support FSC Core
  • You have a Salesforce implementation partner experienced with FSC Core migrations

Migrate Soon (Next 6-12 Months) If:

  • You're stable on the managed package but want to be Agentforce-ready
  • Some ISV partners haven't released FSC Core support yet
  • You have a major project in progress and don't want to disrupt it
  • You need time to build internal readiness (data cleanup, documentation)

Wait (12+ Months) If:

  • You have deep, complex custom code dependencies on managed package objects that require significant refactoring
  • Critical ISV partners have no FSC Core roadmap
  • Your firm is in the middle of a merger or acquisition and the platform is in flux

Our general recommendation: If you're not migrating now, you should be planning for it. Every month you wait is a month of innovation you're not accessing.

How the Managed Package and Core Can Coexist

Here's something many firms don't realize: you don't have to uninstall the managed package to start using FSC Core features. Both can coexist in the same org.

This means you can: 1. Enable FSC Core standard objects 2. Begin configuring new features (ARC, Party Relationship Groups, Financial Account Balance) 3. Run new records through FSC Core while legacy records remain on managed package objects 4. Migrate data gradually (though we recommend entity-by-entity migration for consistency)

This coexistence approach reduces risk and allows for a phased transition. However, avoid running parallel systems indefinitely — the goal should be full migration within a defined timeline.

Frequently Asked Questions

Is Salesforce ending support for the FSC managed package?

Salesforce has not announced an end-of-life date for the managed package. However, all new features, AI capabilities (Agentforce), and innovation are being built exclusively for FSC Core. The managed package will continue to receive maintenance updates but no significant new functionality.

Can I use Agentforce with the FSC managed package?

No. The pre-built Agentforce agents for wealth management require FSC Core standard objects. If you want to deploy Agentforce AI capabilities, you must migrate to FSC Core.

How long does FSC Core migration typically take?

Depending on complexity: 6-16 weeks from planning through go-live. Simpler environments with fewer customizations and integrations can complete in 6-8 weeks. Complex environments with extensive custom code, multiple ISV dependencies, and large data volumes may require 12-16 weeks.

How much does FSC Core migration cost?

Implementation costs typically range from $40,000 to $150,000+ depending on the scope of customization, number of integrations, data migration complexity, and testing requirements. There are no additional Salesforce licensing costs — FSC Core is included in the FSC license.

Will my existing integrations break during migration?

Potentially, if they reference managed package-specific objects or fields. This is why the ISV dependency check and integration update phases are critical. With proper planning, integration disruption can be minimized to the cutover window.

Should I hire a Salesforce partner for FSC Core migration?

We strongly recommend it — especially for firms with complex environments. FSC Core migration touches your data model, integrations, automations, reports, and user experience. A partner with financial services expertise and FSC Core migration experience can identify risks early, avoid common pitfalls, and ensure your compliance requirements are maintained throughout the transition.

Ready to Plan Your Migration?

At Vantage Point, we've been implementing Salesforce Financial Services Cloud since its inception — across both the managed package and FSC Core. Our senior, US-based consultants understand the technical nuances, integration challenges, and compliance requirements that make financial services migrations unique.

Whether you're ready to migrate now or want to build a timeline for the next 6-12 months, we'll help you plan a path that minimizes risk and positions your firm for every capability Salesforce is building for financial services.

Contact us today to start your FSC Core migration assessment.

Vantage Point is a leading Salesforce and HubSpot consultancy specializing in regulated industries. With 150+ clients, 400+ engagements, a 4.71/5.0 average client rating, and an employee-owned team of senior consultants, we deliver compliance-first CRM implementations for financial services, insurance, healthcare, and beyond.