In one sentence: migrating classic Notes and Attachments to Enhanced Notes and Files is a data migration wearing the costume of a settings change, and the two things that catch people are dates and sharing. The free Magic Mover app from Salesforce Labs does the conversion in batch jobs. What it cannot do is decide what happens to your created dates, your community users’ access, or the Apex that queries the Attachment object.
What is actually different
An Attachment has one parent. It lives on that record, it is visible to whoever can see that record, and that is the whole model. A File is a separate record with versions, previews and its own sharing, connected to records through link records, so one file can hang off several records at once.
Classic Notes are plain text on a Note record. Enhanced Notes are rich text, stored as a kind of file, with the same linking model.
That richness is the reason to migrate and the reason it is not trivial. You are moving from a model where access comes entirely from the parent to one where access comes from links, sharing type and a visibility setting.
Before you start
- Turn on Notes in Setup if it is not already on, and check that the Notes and Files related lists are on the layouts where users expect them.
- Count what you have. A query grouped by parent object on Attachment tells you the scale and where the volume sits, which is usually one object you had forgotten about.
- Check your file storage. During migration you hold both copies, so the peak is roughly double the attachment volume until originals are removed.
- Find the Apex, Flows and integrations that read or write
AttachmentorNote. They will not follow automatically and they will keep working against the old objects, quietly writing records nobody migrates.
Running the conversion
The Magic Mover for Notes and Attachments is a free Salesforce Labs app on AppExchange. Install it, choose whether to convert notes, attachments or both, and it schedules batch jobs that create the new records and link them to the same parents. It has an option to delete the originals as it goes and an option to leave them.
Leave them, on the first pass. Convert, let users live with it for a fortnight, then delete. Two weeks of extra storage is cheaper than finding a problem after the source records are gone.
On a large org this runs for days, and the batch jobs queue behind everything else. Schedule it away from your nightly integrations.
The three things that go wrong
Created dates. The new file record is created when the batch runs, not when the attachment was uploaded. Related lists sorted by date suddenly show everything as today, and any process reasoning about “the most recent attachment” needs checking. Verify in a sandbox what your tooling does with dates before you commit, because you only get to be surprised once.
Community and portal visibility. A file link carries a visibility setting that decides whether external users can see it. Get that wrong and every migrated document disappears from your partner or customer community while remaining perfectly visible internally. Test with an actual external user login, not with an admin.
Private attachments. Attachments could be flagged private, restricting them to their owner and administrators. That concept does not map cleanly onto the file sharing model. Decide what happens to those before the batch runs rather than after.
After the migration
Remove the Notes and Attachments related list from layouts once you are confident, because leaving it there gives users two places to put things and guarantees new classic attachments keep appearing.
Update the automation you inventoried earlier. Anything that created an Attachment should now create a ContentVersion and a link. Anything that queried attachments to count or check them needs rewriting against the file objects, and the query shape is genuinely different because the relationship goes through a junction rather than a parent field.
Then check reporting. Any report type built on the old objects returns nothing once the data has moved.
Frequently asked
Do I have to migrate at all? No, classic attachments still function. But new capability is being built on files, the Notes related list is where users now expect to write, and running both models indefinitely means every search for a document happens twice.
Can I migrate one object at a time? Yes, and you should. Start with a low-volume object, verify dates, sharing and external access, then work up to the big one.
What happens to attachments on email messages and tasks? They convert like any other, but check them specifically. Email attachments are high volume and often the single largest slice of the total.