Migrate from Amwork to Salesforce Sales Cloud

Amwork Contacts with lifecycle stage of lead, unqualified, or prospect map to Salesforce Lead. Lifecycle stage of customer, evangelist, or active client map to Salesforce Contact tied to an Account. We compute the split using Amwork's lifecycle_stage and contact_status properties, preserve the original Amwork stage in a custom field amwork_original_lifecycle__c on both Lead and Contact, and flag any contacts with no lifecycle stage for manual classification during UAT.

Amwork Company records map directly to Salesforce Account. Company domain becomes the Account Website field and is used as the dedupe key during import. In multi-workspace Amwork accounts, we check for duplicate companies across workspaces and consolidate before insert to avoid creating duplicate Accounts in Salesforce. Account is created before any Contact import so that the AccountId Lookup is satisfied at the moment of Contact insert.

Amwork Deals map to Salesforce Opportunity. Deal stage maps to Salesforce StageName and pipeline assignment maps to a Salesforce Record Type and Sales Process that we configure before migration. Deal value, close date, and owner assignments migrate directly. Amwork's deal custom properties (closed-lost reason, closed-won reason, product line) become Salesforce custom Opportunity fields.

Each Amwork pipeline stage becomes a Salesforce StageName value within the corresponding Sales Process. Stage probability percentages migrate from Amwork to Salesforce StageProbability, rounded to the nearest integer allowed by Salesforce. If Amwork stages have names not present in the target Salesforce edition's standard stages, we create custom stage values during schema design.

Amwork's customizable deal pipelines map to Salesforce Record Types on Opportunity. Each Record Type gets its own Sales Process that whitelists the relevant stage values, Page Layout assignment, and field-level security profile. This configuration is deployed to a Salesforce Sandbox first for validation before the record migration begins.

Amwork's separate Leads section maps directly to Salesforce Lead. Lead status maps to Salesforce Lead Status. Any Amwork lead score custom property migrates to a custom Salesforce Lead field lead_score__c. Leads without a valid email address are flagged in the reconciliation report and held from import pending resolution.

Amwork Projects have no native Salesforce equivalent. We create a Salesforce custom object Project__c with custom fields for project name, description, status, start date, and end date matching Amwork's project schema. For ongoing project management needs, we recommend a Salesforce-native project tool (Salesforce Flow + Tasks, or an AppExchange project app) as a post-migration implementation scope. The customer's admin selects the preferred approach during scoping.

Amwork custom fields (text, number, date, choice types) attach to records via project-level activation. We create equivalent Salesforce custom fields on the corresponding standard or custom object, mapping Amwork field types to Salesforce field types (text to Text, number to Number, date to Date, choice to Picklist or Multi-Select Picklist). Missing custom fields are created in Salesforce before any record import begins.

Amwork Tasks migrate to Salesforce Task with assignees, due dates, priorities, and parent-child relationships preserved via Salesforce Task relations or a custom parent_task__c lookup. Checklist sub-items on Amwork tasks become Salesforce Task subtasks linked via the WhatId or a custom lookup field. Project membership migrates as a custom field on Task.

Amwork time entries attach to tasks and projects, not directly to contacts or companies. Since Salesforce has no native time tracking object, we convert time entries to read-only Task records with Subject = 'Time Entry: [task name]', Description = '[duration] - [description]', and a custom field time_entry_duration__c in minutes. A time_entry_source__c flag set to 'amwork_migration' marks migrated entries so they can be identified and managed separately from live Tasks.

Amwork file attachments on tasks and deals migrate as Salesforce ContentDocument records linked via ContentDocumentLink to the parent record (Task or Opportunity). Large attachment batches exceeding 10,000 files require chunked migration with rate-limit handling to stay within Salesforce Bulk API throughput limits.

Amwork BPMN-based automation rules and email follow-up sequences are configuration objects, not data records. We do not migrate automation rules as code because they are platform-specific and require re-authoring in Salesforce Flow. We deliver a written inventory of every active Amwork automation rule with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent for the customer's admin to rebuild post-migration.

Amwork User records (name, email, role, active status) map to Salesforce User by email match. Any Amwork user without a matching Salesforce User is held in the owner reconciliation queue. The customer's Salesforce admin provisions missing Users before record migration resumes. Inactive Amwork users become inactive Salesforce Users with their original Owner references preserved for audit.

Amwork Workspaces are top-level organizational units that may span multiple business units. In single-workspace Amwork accounts, we map the workspace to the Salesforce org itself. In multi-workspace accounts, we map each workspace to either a Salesforce Account (if workspaces map to customer organizations) or a custom Division__c object for internal segmentation. The customer chooses the mapping strategy during scoping.