Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short answer: you can convert a lookup to master-detail only if every single child record has that lookup populated, and you can convert back only if you first delete every roll-up summary field that depends on the relationship. The conversion is not a cosmetic change. It rewrites how the child records are owned and shared, and going back does not restore what you had.

Lookup to master-detail: the conditions

Salesforce will refuse the change unless all of these hold:

  • No blank values. Every existing child record must have a parent in that lookup field. One null anywhere stops the conversion, and the error does not tell you which record.
  • Room for another master-detail. A custom object supports at most two master-detail relationships. If it already has two, you are done before you start.
  • Depth. Custom master-detail hierarchies are limited in how many levels deep they go. A conversion that would push the chain past the limit is rejected.
  • The parent side. A standard object can be the master of a custom object, but never the detail. You cannot make Account the child of anything.

Find the nulls first, because that is what fails:

SELECT COUNT(Id) FROM Invoice_Line__c WHERE Invoice__c = null

What actually changes

This is the part that gets skipped in the planning meeting.

  • Ownership disappears. Detail records have no OwnerId. The field is gone from the object. Any report grouped by owner, any assignment rule, any queue, any formula referencing Owner.Name on the child stops working.
  • Sharing is inherited. The child’s visibility is entirely determined by the parent’s. Sharing rules on the child object are deleted, because they no longer have anything to act on. The child’s own organisation-wide default is gone too. It follows the master.
  • Delete cascades. Delete the parent and the children go with it. This is often the reason people want master-detail, and it is also the reason a bad merge takes out ten thousand rows.
  • The field becomes required. It shows on the layout as required and cannot be blanked.
  • Reparenting is off by default. There is a checkbox on the relationship to allow it. Without it, a child cannot be moved to a different parent after creation, by anyone, including an admin with a data loader.
  • Roll-up summaries become available. The reward. Count, sum, min and max on the parent, calculated by the platform.

Master-detail back to lookup

The blocking condition is roll-ups. Every roll-up summary field on the parent that summarises through this relationship has to be deleted first, and deleting a roll-up deletes the values it held. If those numbers appear in reports, dashboards, formulas or an integration, you are not deleting a field, you are removing a data point that other things depend on.

Capture the values before you delete. An export of the parent IDs and the roll-up values gives you something to reconcile against once you have rebuilt the calculation with a flow or scheduled Apex.

On the way back, the child records need owners again. The platform assigns ownership as part of the conversion, and the result is rarely what the business would have chosen. Plan an ownership pass immediately afterwards, driven from whatever field actually indicates who should own each record. Sharing also resets: the child object gets its own org-wide default, which you should set deliberately before the conversion rather than discovering it afterwards at Public Read/Write.

The safe sequence

  1. Count the nulls, fix them, count again.
  2. Export the child records with their current owners and any sharing that matters. You will want this if you ever convert back.
  3. Record every roll-up you plan to create, and every automation that references the child’s owner.
  4. Do the conversion in a sandbox with production-shaped data, not an empty developer org, because the failure modes are all about existing rows.
  5. Time it. On a large object the change runs as a background job and can take a long while, during which the object is being rewritten.

Frequently asked

Can I convert with data in place? Yes, that is the normal case. The conditions above are all about the data, which is why an empty sandbox tells you nothing useful.

Do I lose the roll-up values when converting to lookup? Yes, along with the fields. Export them first.

Is there a way to get roll-ups without master-detail? Yes. A record-triggered flow, scheduled Apex, or a declarative roll-up tool. Slower and not transactional, but it leaves ownership and sharing alone, which is often worth more than the accuracy of the moment.