Migrate from Fat Free CRM to Salesforce Sales Cloud

Fat Free CRM accounts table maps directly to Salesforce Account. We extract name, website, phone, and assigned user (owner) from the accounts table. The Account is created before any Contact import so that AccountId lookup is satisfied at the moment of Contact insert. Multi-address billing and shipping in Fat Free CRM maps to Salesforce BillingAddress and ShippingAddress fields respectively.

Fat Free CRM contacts table maps directly to Salesforce Contact. The contact_accounts join table is resolved during migration: every Contact with an assigned account gets AccountId populated from the matching Account record. Contacts without a matching Account are held in a reconciliation queue for the customer's admin to create Account records or map to an existing placeholder Account. Name, email, phone, title, and department migrate directly.

Fat Free CRM leads table maps directly to Salesforce Lead. Status (new, contacted, converted, rejected), source (web, referral, trade show), and rating (cold, warm, hot) migrate as custom or standard Lead fields. The assigned user maps to OwnerId via email matching against the Salesforce User roster. Note that Salesforce Lead converts to Contact-Account pair; Fat Free CRM leads do not have a separate conversion step in the source.

Fat Free CRM opportunities map to Salesforce Opportunity. Stage, amount, probability, and close date migrate directly. The opportunity_contacts join table is resolved by creating OpportunityContactRole records for each associated Contact after both Opportunity and Contact inserts are complete. The assigned account maps to AccountId from the Account lookup.

Fat Free CRM tasks belong to a user and optionally to an Opportunity or Contact. Title, body (description), due date, category, and completion status migrate to Salesforce Task. Status open and pending map to Not Started and In Progress; completed maps to Completed. The WhatId lookup (parent Opportunity or Account) and WhoId lookup (parent Contact or Lead) are resolved at migration time using the extracted IDs and the newly created Salesforce IDs.

Fat Free CRM campaigns track name, status (planned, launched, completed, suspended), budget, and target metrics. We import campaign records directly. Campaign membership (which contacts belong to which campaigns) is stored via tag subscriptions in Fat Free CRM; we rebuild these as CampaignMember records linking the migrated Contact IDs to the migrated Campaign IDs.

Fat Free CRM uses a global acts_as_taggable tagging system across Contacts, Accounts, Opportunities, and Leads. Tag tokens are stored in a separate table with polymorphic associations. We offer two strategies during scoping: migrate tags to a Salesforce custom text field (comma-delimited) on each object, or use Salesforce Topics with TopicAssignment records for cross-object classification. The customer chooses the strategy; the default is a custom text field per object.

Fat Free CRM supports custom fields on Accounts, Contacts, Leads, and Opportunities via a serialized field or extension table. We extract the custom field definitions during schema discovery, map field names to Salesforce __c custom field API names, and map data types (string, integer, date, boolean) to equivalent Salesforce field types. Custom fields are deployed to the destination Salesforce org via metadata API before any data import begins.

Fat Free CRM user records (login, email, role, team membership) are exported as a reference table. We do not create Salesforce User records because that requires destination admin credentials and write access to the Salesforce org user directory. The user roster is delivered as a CSV with user email, role, and team so the customer's Salesforce admin can provision matching User accounts before record ownership is assigned.

Fat Free CRM groups are organisational units for access control and data sharing. This concept does not map directly to a first-class Salesforce object. We export the full group roster and group membership as a reference table. The customer's admin decides whether to recreate groups as Salesforce Public Groups (for sharing rules) or Queues (for Lead and Case assignment). We do not create these objects automatically.

Fat Free CRM users and teams (active, inactive status, admin vs user role) are extracted as a reconciliation reference. The migration user is assigned as the interim OwnerId on all migrated records until the customer's Salesforce admin provisions active User accounts and we remap OwnerId references from the reference table. This is a prerequisite step before production migration begins.

Fat Free CRM's plugin system can add columns to core tables or create entirely new tables beyond the standard Rails schema. We run a schema discovery phase against the live database before extraction to capture any plugin additions. Each discovered plugin column is mapped to a Salesforce custom field (__c) or custom object depending on whether it is a field on an existing object or a new relational table. Undiscovered plugin columns that surface post-extraction require a supplementary pass documented in the reconciliation report.