Salesforce to Factory Labs: A Migration Playbook for Distributors

CRM migrations have a deserved reputation for going badly. Most of the public stories are about Fortune 500 deployments where the migration ran two years and three quarters over budget. The smaller migrations distributors actually run fail in the same ways, just with smaller blast radius. This post walks through how to do the move from Salesforce to Factory Labs without recreating the failure modes.

The playbook below assumes a distributor with one to fifty seats, a single Salesforce production org, and an existing ERP that the new CRM will read directly. Larger Salesforce footprints (multiple orgs, Service Cloud + Sales Cloud + Marketing Cloud + Pardot, heavy Apex customization) need a different playbook that we are not going to write here. Most of those migrations should be staged over multiple quarters.

The three failure modes

Almost every CRM migration that derails fails in one of three ways. Knowing the names lets you spot the patterns early.

Lift-and-shift. The team treats the migration as a data move. They export every Salesforce object, write a transform script, import everything into the new CRM, and declare victory. Six weeks later the new CRM has 80,000 records, of which 73,000 are stale leads from a 2019 conference, dead accounts whose primary contact left in 2021, and abandoned opportunities that nobody can explain. The team is now drowning in someone else's data exhaust. Mitigation: migrate intentionally, not exhaustively.

Custom-object fundamentalism. The team has spent years building Salesforce custom objects (Order_Line__c, Inventory_Snapshot__c, Quote_Header__c, Territory_Assignment__c) and tries to recreate every one of them in the new CRM. Three months later they have rebuilt the same data model in a new shell, complete with the same drift issues that motivated the migration in the first place. Mitigation: if the data lives in the ERP, leave it there. The new CRM reads it live.

Frozen-in-place workflows. The team migrates the workflows exactly as they exist (every approval rule, every email template, every process builder flow) instead of asking which of them is still serving a purpose. The result is a new CRM that behaves like the old CRM, including the workarounds the team had developed to escape the old CRM's limitations. Mitigation: a migration is the rare opportunity to rebuild from intent rather than precedent. Take it.

The rest of this post is structured around avoiding each of those three.

Phase 1: inventory and decide

Before any data moves, two artifacts get produced.

Artifact 1: the object decision matrix. List every Salesforce object, both standard (Account, Contact, Lead, Opportunity, Case, Task) and custom, and assign one of four dispositions: migrate, leave behind, merge, or move-to-ERP.

Migrate. The object holds CRM-native data that does not live in the ERP. Account (the relationship layer, not the billing entity), Contact, Opportunity (the deal pipeline), Case, Task, Activity.
Leave behind. The object held data that was meaningful in Salesforce but does not need to come along. Examples: Lead records older than 18 months with no activity; Opportunity records closed-lost more than 12 months ago; campaign objects from defunct programs.
Merge. The object is one of N custom approximations of the same thing. Distributors often have Account__c, Customer_Master__c, Bill_To__c, Ship_To__c that should all collapse into a single Account record in the new CRM. The ERP usually has the canonical version.
Move-to-ERP. The object is holding data the ERP already owns. Order_Line__c, Inventory_Snapshot__c, Quote_Header__c, Contract__c, Pricing__c. Do not migrate these. The new CRM reads them live from the ERP.

The output is a one-page table. Most teams find that 40-60% of their Salesforce objects fall into "leave behind" or "move-to-ERP." That is the single largest source of migration acceleration.

Artifact 2: the workflow decision matrix. List every Salesforce workflow, process builder flow, approval process, and Apex trigger. For each, write one sentence describing what business outcome it produces. Then assign one of three dispositions: rebuild, retire, or replace.

Rebuild. The workflow produces a real outcome that the team still relies on. Recreate it in the new CRM as a native automation. The new version is often shorter because the new CRM's primitives match the workflow's intent more directly.
Retire. The workflow exists for historical reasons and nobody can name what would break if it were turned off. Turn it off. (Two weeks of monitoring usually confirms nothing breaks.)
Replace. The workflow is a workaround for a Salesforce limitation. Examples: a flow that copies Opportunity data to a custom object so a report can reference it; a trigger that nightly recalculates fields because formula fields would not scale. These workarounds are usually no longer needed because the new CRM does the underlying thing natively.

Most teams find that 50-70% of their Salesforce workflows fall into "retire" or "replace." That is the second largest source of acceleration.

Phase 2: data migration mechanics

Once the matrices are done, the data move itself is straightforward.

Step 1: Export from Salesforce. Use the standard Data Loader (or the Bulk API) to export each object the matrix marked "migrate." Keep the export raw; do not transform during export. The Factory Labs migration utility takes Salesforce CSV exports directly and handles the normalization in one place where it can be audited.

Step 2: Map IDs. Salesforce uses 18-character IDs. Factory uses UUIDs. The migration utility maintains a Salesforce ID to Factory UUID mapping table for the duration of the migration, which lets foreign keys (Contact to Account, Opportunity to Account) resolve correctly in the new CRM.

Step 3: Map custom fields. Standard fields map automatically. Custom fields on standard objects (Account.Annual_Spend__c, Contact.Preferred_Channel__c) map to Factory's JSONB-backed custom fields, which means there is no schema migration to run. The field exists on the first record that uses it.

Step 4: Import in order. Accounts first, contacts second, opportunities third, activities last. The migration utility enforces this so foreign key references resolve correctly.

Step 5: Spot-check, do not full-audit. A common failure mode is to spend three weeks comparing record counts and reconciling rounding differences. Most of those differences are noise. Instead: pick 20 accounts at random (10 active, 10 historical) and walk through them in both systems with the rep who owns them. If the rep says "this looks right," it is right. If they say "where is X," that is a real bug worth fixing. A 20-account spot check catches the structural bugs without burning three weeks on cosmetic ones.

The Starter and Growth tiers of Factory Labs include this full migration utility. The Professional tier adds custom-object migration; the Enterprise tier adds white-glove workflow migration. See /pricing for the current breakdown.

Phase 3: workflow rebuild

The matrices from Phase 1 dictate this phase. Rebuild only what the matrix marked "rebuild." For everything else:

Retired workflows are simply not recreated. After two weeks of operating without them, validate with the team that nothing was missed.
Replaced workflows get the new-CRM-native version. Most teams find this is 20-40% the line count of the original because the workarounds are gone.

A particularly common replacement: Salesforce flows that batch-update opportunities at midnight to keep aggregate fields fresh. The new CRM computes those aggregates at read time, so the entire flow disappears. Similar story for the flow that copies fields between custom objects to make a report joinable; the new CRM joins them in the query layer.

Phase 4: cutover

Cutover is one day, not one weekend. The mistake teams make is treating cutover as a big-bang event with a freeze window that lasts a weekend, during which the team is supposed to validate everything. By Monday they are exhausted and have validated nothing.

The pattern that works:

T minus seven days: Run the migration into a Factory Labs sandbox. The sales team gets read-only access. Anyone who finds a bug files it.
T minus three days: Re-run the migration with the bug fixes applied. The sales team confirms.
T minus zero (a Tuesday morning, not a Friday night): Salesforce goes read-only. Factory Labs goes live. The sales team uses Factory Labs starting at 9 AM. Salesforce stays available for historical lookups for 60 days, then is exported to S3 and shut down.

The reason for a Tuesday: if anything goes wrong, the team has four working days to get help. A Friday-night cutover means the team is debugging by themselves on Saturday morning with vendor support 48 hours away.

What you do not migrate

The single most underrated migration acceleration is choosing not to migrate things. The defaults:

Closed-lost opportunities older than 12 months. They have no predictive value, they will not be re-engaged, and they clutter every search.
Leads with no activity in 18 months. Same logic.
Campaign objects from defunct campaigns. They produce no decisions; they are pure overhead.
Custom objects holding ERP data. The new CRM reads from the ERP directly. Leaving these in Salesforce is fine; they decay there and eventually get exported to cold storage.
Apex triggers that wrap things the new CRM does natively. Do not port them; replace them.

The empty space matters. A CRM that has 18 months of recent, high-signal data is easier to operate than a CRM that has 8 years of accumulated everything.

What changes day one

For sales reps, day one looks like this:

The account page shows live order history pulled from the ERP. No more "let me check the ERP tab."
Lead and opportunity pipelines look familiar. Custom fields are where they expect them.
Salesforce reports they relied on are reproduced in the Factory Labs reports module, with the same numbers, sourced from live ERP queries instead of nightly sync extracts.
The mobile app works. The CRM app on the phone is the same CRM as on the laptop, with the same data.

For sales ops, day one looks like this:

The reconciliation report that runs every Monday morning comparing Salesforce opportunity totals to ERP order totals is no longer needed. The opportunity is the order, viewed differently.
The Boomi or MuleSoft instance previously bridging Salesforce and the ERP can be turned off. (Wait two weeks before deleting, just to be sure.)
The custom-object schema management work is gone. Custom fields live in JSONB; adding a field is a UI action, not a deployment.

For leadership, day one looks like this:

The CRM bill is lower.
The middleware bill is gone.
The reconciliation overhead in sales ops is reclaimed for actual work.

What we will write next

This is the high-level playbook. The Factory Labs docs include the operational guides: /docs/guides/migration for the data move mechanics, /docs/admin/automations for workflow rebuild, and /docs/admin/custom-fields for the custom field model. If you want the cost side of the decision, the next post in this series ("The Real Cost of Salesforce + Boomi vs. ERP-Native CRM") goes through that in detail.

If you want to talk through a specific migration before reading the docs, /contact goes to the team.