.webp)
.gif)
Migrating Salesforce records to a new Record Type means updating the RecordTypeId field across every affected record while keeping validation rules, Flows, Apex, and approval processes aligned to the new configuration. Skip the audit step and automations break silently. This article covers the five-phase process CRM teams use to migrate Record Types without breaking existing business logic.
A Salesforce Record Type controls three things for a given record: which picklist values are available, which page layout the user sees, and which business process the record follows. Record Types let organizations offer different processes to different users on the same object. Migrating to a new Record Type means every affected record gets a new RecordTypeId, which can change its picklist options, its layout, and which Sales Process governs it. This is why a migration is never a pure data update. It touches every piece of automation that reads or filters on RecordTypeId.
Validation rules, Flows, Apex triggers, approval processes, and even report filters frequently reference a specific Record Type, either by hardcoded ID or by name. When you swap the RecordTypeId on a record, any automation still pointing at the old configuration either stops firing or fires incorrectly. Salesforce recommends no more than 200 Record Types per object, so most migrations consolidate several older types into fewer, cleaner ones rather than creating a like for like replacement. Planning the migration around this constraint upfront avoids a second cleanup project a year later.
Before touching any data, find everything in the org that references the old Record Type. This includes hardcoded IDs in validation rule formulas, entry criteria on approval processes and assignment rules, cross-object formulas and rollups on related objects, and filters on reports and list views. Skipping this step is the single most common cause of a failed Record Type migration, because the data update succeeds while the dependent automation quietly breaks. Document every component you find before moving to the next phase, and treat the audit as complete only when every automation type below has been checked.
Record-triggered Flows deserve particular attention, since their Start element uses entry conditions to decide whether the Flow runs at all. If a Flow's entry conditions filter on the old RecordTypeId, the Flow will simply stop firing on migrated records without throwing any error, which makes this failure mode easy to miss during testing. Reviewing every record-triggered Flow's Start element against your Record Type inventory is not optional. It is the step most audits skip and most rollbacks trace back to.
Create the new Record Type before you touch any existing data, and confirm it is assigned to the correct Page Layout and, where relevant, a Sales Process. This sequencing matters because Data Loader rejects an update if the target RecordTypeId is not yet active and properly configured. Implementation guidance from experienced Salesforce practitioners consistently flags backing up your data before any Record Type change as essential practice, regardless of scale. Confirm picklist values are correctly scoped to the new type, since a mismatch here surfaces as a validation error the moment the migrated record is next edited by a user.
Export the records that need migrating using Reports, Data Loader, Workbench, or an ETL tool, and include each record's current RecordTypeId in the extract. In a spreadsheet, add a column for the new 18 character RecordTypeId and map every old value to its replacement. Salesforce requires the 18 character, case-insensitive ID format for API-driven updates rather than the 15 character ID shown in some UI views, so confirm you are copying the correct version before building the mapping file.
Keep this mapping file, since the clean-up work covered in our Salesforce data migration guide depends on knowing exactly which old ID mapped to which new one.
Run the update in a sandbox first to catch dependencies the audit missed, since a change to RecordTypeId cannot be reversed once committed to production. Salesforce's own support guidance recommends testing with two or three records before running a full batch, precisely because the change cannot be undone through Data Loader itself.
Change management practice recommends documenting every step before it ships and monitoring the Setup Audit Trail after the deployment completes, since a Record Type migration can quietly affect permissions or automation elsewhere in the org. Treat the sandbox run as a rehearsal for the exact production sequence, not a rough approximation, since differences between sandbox and production environments are where migrations most often go wrong.
Update every hardcoded reference flagged during the Phase 1 audit so each one points at the new Record Type instead of the old one. Once no active or historical record depends on the old Record Type, deactivate or delete it, since Salesforce does not allow deletion while records still reference it. Keep the mapping file and a full data export from before the migration. Because the RecordTypeId change is irreversible, this backup is the only recovery path if a mapping error surfaces after the fact. Teams that have already worked through Salesforce license and Queue clean-up will recognize the pattern: treat clean-up as part of the migration itself, not an optional follow-up task.
No. Updating RecordTypeId through Data Loader is not reversible, and Salesforce's own guidance recommends testing with two or three records before running a full batch. If a mapping error surfaces afterward, the only recovery path is reloading from a pre-migration data export, which is why exporting current RecordTypeId values before you start is a required step, not an optional precaution.
RecordType.DeveloperName is a stable reference to a Record Type by name rather than by its 15 or 18 character ID, which changes between sandboxes and orgs. Hardcoded IDs break the moment you deploy to a different environment or migrate the Record Type itself. Validation rule formulas and Apex that reference DeveloperName instead of a literal ID survive both scenarios without modification.
Two or three, according to Salesforce's own support guidance, since the RecordTypeId change cannot be reversed once committed. Confirm the small batch behaves correctly, check that dependent automation still fires as expected, and only then proceed to the full production batch. Skipping this step is the fastest way to turn a migration into a data recovery project.
Salesforce recommends no more than 200 Record Types per object, even though the platform does not enforce a hard technical limit at that number. Most migrations are a good opportunity to consolidate several overlapping older Record Types into a smaller, cleaner set rather than creating a one to one replacement, which keeps the object easier to maintain going forward.
No. Salesforce does not allow a Data Loader update to set RecordTypeId to Master or to a null value. The target must be an active, properly configured Record Type. Confirm the new Record Type is fully set up, including Page Layout and Sales Process assignment, before attempting the bulk update, or the load will fail.
Yes, even for a handful of records. Sandbox testing exists specifically to catch dependent automation issues before they reach production. Skipping it for a high impact, irreversible change like a Record Type migration is exactly the scenario sandbox testing guidance most explicitly warns against, regardless of how few records are involved.
Presenting our distinguished clientele! We collaborate closely with visionary B2B tech and software companies, intricately shaping their comprehensive Revenue Architecture. Take a look at who we have already served.
Explore our captivating customer success
stories here.
You have questions? Our Founder and Managing
Partner Michael is looking forward to hearing from
you.
