Migrate from Prophet CRM to Mailchimp

Prophet Contact records map directly to Mailchimp Subscribers in the designated Audience. Standard fields including first name, last name, email address, phone, title, address, and subscription status export from Prophet's OData API and map to Mailchimp's corresponding subscriber fields. We freeze Prophet's bidirectional Outlook Contact sync before extraction to prevent duplicate records post-import, then verify the email address as the primary dedupe key during Mailchimp import. Any contacts with duplicate emails are deduplicated using Prophet's most recently updated record.

Prophet Company records map to a Mailchimp tag named after the company plus merge fields carrying company-level data. We create a company:COMPANYNAME tag on each related Contact and populate MERGECOMPANY, MERGEINDUSTRY, MERGEWEBSITE, and MERGEEMPLOYEES merge fields on the subscriber record. This reconstructs the Prophet contact-company hierarchy within Mailchimp's flat subscriber model using tags for grouping and merge fields for company attributes. Company records with no related Contacts are held in a named 'orphaned-accounts' tag for the customer's admin to resolve.

Prophet Opportunities have no direct Mailchimp equivalent because Mailchimp does not store deal value, pipeline stage, probability, or close date as structured records. We map opportunity data to a tag opportunity:OPPNAME on the related Contact and append deal details (value, stage, close date) as a structured note on the contact's activity timeline. Pipeline stages and probability percentages are documented in a written Opportunity Inventory delivered alongside the migration so the customer's admin can enter deal context manually in Mailchimp notes or a connected spreadsheet.

Prophet Activities (email tracking, tasks, appointments, call logs) linked to Contacts map to Mailchimp contact notes. We extract activities via OData pagination, group them by contact, and append them as timestamped notes in descending chronological order with activity type, subject, and outcome. Calls, meetings, and tasks without email engagement are stored as tags (activity:call, activity:meeting, activity:task) to distinguish them from email history visible in Mailchimp's campaign reporting. Activities linked only to Opportunities with no related Contact are stored as notes on the Contact tagged with the corresponding opportunity:OPPNAME tag.

Prophet custom fields on Contacts and Companies vary by department template, which means the effective field schema can differ per department even on the same object. We audit all department templates during scoping, enumerate field names and data types across departments, and consolidate unique custom fields into Mailchimp merge fields. Text fields map to text merge fields, picklists map to radio or dropdown merge fields, and date fields map to date merge fields. Fields that exist only in specific departments get a departmental tag (dept:SALES, dept:MARKETING) alongside the merge field to preserve the department context. This audit step is mandatory before any export begins; skipping it risks dropping department-specific fields not visible in the default view.

Prophet file attachments on Companies, Contacts, and Opportunities extract as metadata (filename, URL reference, file type, upload date, linked record) from the OData export. We upload files to the customer's designated cloud storage (SharePoint, Google Drive, or S3) and store the file URL and description as a note on the related Mailchimp contact. Mailchimp's native attachment support is limited to campaign asset uploads, so file attachments on contact and company records do not migrate as Mailchimp-native files; the note preserves the reference so the customer's team can access the original document at the stored URL.

Prophet departments are first-class records with custom templates, configurable cross-department access, and role-based permissions. Mailchimp has no department concept. We map department assignments to tags (dept:DEPTNAME) on the relevant Contact records and document the department schema, template fields, and access configuration in a written Department Inventory delivered alongside the migration. Cross-department access rules and role-based permissions do not transfer to Mailchimp because Mailchimp's access model is audience-level with user roles (Admin, Author, Manager, Viewer) that do not map to Prophet's department-scoped permissions.

Prophet pipeline stages are configurable per department and carry probability percentages. Mailchimp does not have a pipeline or stage concept. We map each Prophet pipeline stage to a tag (stage:STAGENAME) on the related Contact or Opportunity-tagged Contact. Stage names and probabilities are documented in a written Pipeline Inventory for the customer's admin to reference. Closed-Lost and Closed-Won stages map to tags (stage:Closed-Won, stage:Closed-Lost) to preserve deal outcome history at the contact level.