Migrate from Fat Free CRM to Microsoft Dynamics 365 Sales

Fat Free CRM accounts table (name, website, phone, billing address, assigned user) maps directly to Microsoft Microsoft Dynamics 365 Sales Account. The account.id primary key is not preserved; we use the account name plus website as the Dynamics 365 Account dedupe key during import. The assigned user maps via email-match to the Dynamics 365 User lookup once the user roster is reconciled in the approach step. If Fat Free CRM stores shipping address separately, it maps to the Account's ShippingAddress fields.

Fat Free CRM contacts (first_name, last_name, email, phone, title, account_id) map to Dynamics 365 Contact. The contact_accounts join table preserves the many-to-one Account relationship; we resolve the AccountId lookup by matching the Fat Free CRM account_id to the Account record inserted in the previous step. Tags on contacts migrate as a multi-select text field (ff_crm_tags__c) because Dynamics 365 has no native global tagging equivalent at the Contact level.

Fat Free CRM leads store status, source, rating, assigned user, and optional custom fields. They map to Dynamics 365 Lead with statuscode mapping (new, contacted, qualified, unqualified) from the Fat Free CRM status enum. The lead_source maps to the Dynamics 365 leadsourcecode picklist. Any rating (cold, warm, hot) from Fat Free CRM populates a custom field ffc_rating__c if the customer's process relies on it.

Fat Free CRM opportunities track stage, amount, probability, close_date, assigned account, and assigned contact via join tables. We map to Dynamics 365 Opportunity with AccountId resolved from the account reference, close date mapped to estimatedclosedate, amount to estimatedvalue, and stage to the Microsoft Dynamics 365 Sales stage picklist. The opportunity_contact join table preserves which contact is the primary decision-maker on the deal.

Fat Free CRM tasks belong to a user and optionally to an Opportunity or Contact, with title, body, due_date, category, and completion status. We map to Dynamics 365 Task with regardingobjectid resolved to the correct Contact or Opportunity lookup. Completed tasks import with statecode=1 (Completed); open tasks import as statecode=0. The category field migrates as a custom field ffc_category__c if the customer's workflow relies on task categorization.

Fat Free CRM campaigns track name, status, budget, and target metrics. We map to Dynamics 365 Campaign directly. The tag_subscriptions join table stores which contacts are members of which campaign; we rebuild these as CampaignMember records by querying the tag and subscription tables and inserting CampaignMember with status='sent' or the equivalent campaign member statuscode.

Fat Free CRM uses a global acts_as_taggable tagging system across Contacts, Accounts, Opportunities, and Leads. Because Dynamics 365 has no native cross-object tagging, we map tags per entity: tags on Contacts become a multi-select text field ffc_tags__c on Contact; tags on Accounts become ffc_tags__c on Account; tags on Leads become ffc_tags__c on Lead. The customer selects this strategy during scoping. We preserve the full tag token list per record.

Fat Free CRM internal user IDs and group IDs have no meaning in Dynamics 365. We extract the full user roster (id, email, first_name, last_name, role) and group structure as a reference table. Dynamics 365 User accounts must be provisioned manually by the customer's tenant admin before record import, because OwnerId on every standard object requires a valid Dynamics 365 User reference. We provide the reconciliation table mapping Fat Free CRM user IDs to the provisioned Dynamics 365 User IDs.

Fat Free CRM supports custom fields on Accounts, Contacts, Leads, and Opportunities via serialized fields or extension tables added by plugins. We run a schema discovery phase against the live database before extraction to enumerate all custom columns. Each discovered custom field is pre-created in Dynamics 365 as a custom column (type-matched: text to single-line text, date to datetime, number to whole number or decimal) before data import begins. Plugin-extended fields discovered after extraction require a supplementary pass.