Quick answer
If the “Change Field Type” button is missing for a Master-Detail field, it usually means Salesforce is preventing the conversion because that relationship is used by other metadata or package constraints. The most common causes are roll-up summary fields on the parent, namespace/managed-package ownership of the field, or other metadata references (flows, formulas, Apex, validation rules, etc.).
Why this happens — common reasons
1. Roll-Up Summary fields exist on the parent
Roll-up Summary fields on the parent summarize child records using the Master-Detail relationship. Converting to a Lookup would break those roll-ups, so Salesforce disables the change. Check the parent object for any Roll-Up Summary fields and remove them before converting.
2. The field or objects are part of a managed package
If the field was installed from a managed package (has a namespace), Salesforce prevents changing the field type. Fields delivered by packages can only be changed by the package publisher.
3. Active metadata references
If the Master-Detail field is referenced by other metadata — formulas, validation rules, workflows, process builders, flows, Apex code, triggers, reports, list views, Visualforce, or Lightning components — Salesforce may block the conversion until you remove or update those references.
4. Field is required/Shared ownership or sharing settings constraints
Master-Detail implies sharing and ownership behavior controlled by the parent. If your org configuration (sharing rules, ownership model) or certain dependencies rely on that behaviour, conversion may be blocked until you resolve the related configuration.
How to diagnose (practical steps)
Follow these checks in order — they are quick, low-risk, and will usually reveal the blocking dependency:
Step 1: Check for Roll-Up Summary fields
Setup → Object Manager → Parent Object → Fields & Relationships → look for fields of type Roll-Up Summary. If any exist that summarize the child object in question, delete or re-create them after conversion.
Step 2: Check if the field is managed (packaged)
Open the field definition: if its API name includes a namespace prefix (like ns__Field__c) or the field detail shows “Managed Package”, you cannot change it — contact the package vendor.
Step 3: Search for references
Search your org for references to the field: use the Developer Console / VS Code (workspace search), Workbench, or the Setup Global Search for Flows, Processes, Apex classes and triggers, validation rules, formula fields, reports, and list views. Update or remove references before converting.
// Example: Use VS Code global search to find references to MyObject__c.MyMasterDetail__c
// Search term: MyMasterDetail__c
Step 4: Review sharing and required behaviors
Understand implications on sharing model and ownership. If your child object’s access and ownership are tied to the parent (via the master-detail), plan to reconfigure sharing rules or make the lookup required, if needed.
How to perform the change (high level)
1. Remove roll-up summary fields on the parent that reference the master-detail.
2. Update or remove references to the relationship in formulas, flows, Apex, validation rules, processes, reports, and layouts.
3. If the field is packaged, contact the package provider.
4. After cleaning up dependencies, open the Master-Detail field in Setup — the Change Field Type button should now be visible. Proceed to change it to Lookup and test thoroughly in a sandbox first.
Testing & rollout tips
– Always perform the conversion first in a sandbox and run regression tests.
– Backup metadata (using Change Sets or Salesforce CLI) and data (export child records).
– After conversion, re-create necessary automation (roll-ups, flows) now appropriate for lookup relationships (consider declarative roll-up tools if needed).
– Communicate the change to affected teams, because sharing and ownership semantics may change.
Summary
The missing “Change Field Type” button is Salesforce’s safeguard against breaking dependencies. The most common blockers are roll-up summary fields and managed-package ownership. Identify and remove or adjust dependencies, test in sandbox, and then convert.