How to Migrate Off the Salesforce Data Mask Managed Package Before It Goes Read-Only

The Salesforce Data Mask managed package lost support on 9 July 2026, and its display becomes read-only on 31 December 2026. Your masking configurations do not move across to the replacement. You re-create them as new policies in Data Mask & Seed (or in another masking tool), check field by field that they mask what they should, and then uninstall the old package. That leaves about eight weeks. This guide sets out the work in order, and marks which steps Salesforce documents and which are our recommendation.

What Salesforce says, as of 3 November 2026

Salesforce updated its knowledge article on 5 October 2026 and renamed it "Data Mask Managed Package Retirement". Three statements in it set the deadline:

• "Data Mask managed package will be read-only starting December 31, 2026."
• "The Data Mask managed package's support ended on July 9, 2026, and any issues which arise will not be fixed."
• "We strongly encourage customers to transition as soon as possible."

The replacement is Data Mask & Seed. The same article says it "has been available to all customers since the Summer '26 release on July 18, 2026, as a Core application requiring no installation."

The older product documentation, now titled "Secure Your Sandbox Data with Salesforce Data Mask (Legacy)", still uses different wording: "The Data Mask managed package reaches end of service on December 31, 2026." Read the two together. Support has already gone, and 31 December is the date the package goes read-only.

Salesforce does not spell out what read-only allows in practice. Our reading is to plan on viewing old configurations after 31 December and nothing more. Do not plan on running a masking job from the old package in January.

What carries across and what does not

Policies do not migrate. The knowledge article says to "create new masking policies to replace your existing masking configurations, as new functionality is only available through newly created policies." Every configuration you built in the managed package has to be built again.

Custom libraries do. The same article: "Custom Libraries do not require migration or recreation, as they are unified between both the managed package and the Core application."

The licence is separate. Salesforce's documentation lists Data Mask & Seed as available in Professional, Enterprise, Unlimited and Developer Editions "with the Salesforce Data Mask add-on license". Salesforce's pricing page lists Data Mask & Seed at "10% of net spend", with the note that the page "is provided for information purposes only and subject to change." Confirm your figure with your account executive; our licence guide covers what to ask.

The migration, step by step

1. Find who uses the managed package

Salesforce's article gives the path. In Setup, open Company Information, click the Permission Set Licenses link, find Data Mask User and click View Users. That list is everyone with access to the old package. Those people own the configurations you are about to rebuild.

2. Write down every masking configuration

Do this before you touch the new app. For each configuration, record the objects, the fields, the masking type for each field, any record filters, the sandboxes it runs against and how it is triggered. This document is what you rebuild from. It is also the checklist you validate against in step 6.

3. Confirm the licence and assign access

Data Mask & Seed needs the add-on licence above. Ask your account executive in writing whether your existing Data Mask entitlement carries across, and for how many users. Then assign access. Salesforce's requirements page names a Permission Set License and a Permission Set, both called Data Mask And Seed User, and says: "Make sure to assign the Permission Set License before assigning the Permission Set."

4. Re-create each configuration as a new policy

Build one policy per configuration in your inventory. Data Mask & Seed suggests a masking option for fields it identifies as personal data. Salesforce says this detection "evaluates an object field's Sensitivity value and the field's Categories value". It can only be as good as those field labels. Compare every suggestion against your inventory instead of accepting the defaults. If your sandboxes hold data from several countries, the knowledge article says each policy can set a locale, with 35 language choices, so masked addresses and phone numbers match local formats.

5. Check the job limits before the first run

Salesforce's "Data Mask & Seed Requirements and Limitations" page sets limits that affect how you split policies:

• Above 20,000,000 records in a job, the app "doesn't preserve existing data distributions" and "doesn't apply consistent field masking across objects".
• A job is capped at 350,000,000 records. A job over the cap is cancelled before any masking happens.
• Each sandbox can run at most 12 masking jobs in a rolling 24-hour window.
• On the User object, only three user types are masked: PowerCustomerSuccess, CustomerSuccess and CspLitePortal.
• Deleting Feed Items and History records during a job does not bypass automations. Duplicate Detection is not bypassed either, "unless the user manually disables the automation before the masking job".

We cover what these limits mean in practice in what Data Mask & Seed still doesn't do. If your largest Full sandbox is over 20 million records, decide now whether cross-object consistency matters to your testers. If it does, split policies by object or filter records so each job stays under the threshold.

6. Pilot on one sandbox and validate field by field

Masking cannot be undone. Salesforce's legacy documentation says: "When you mask sandbox data, you can't unmask it." Run the first job on a non-critical sandbox you can refresh again. Then go through the inventory from step 2 and confirm each field. Check that the value changed, that it changed into the right kind of value, and that related records still line up. A rule that silently misses a field does not raise an error. It leaves real data in a sandbox that many people can open. The deliverable is a list of named fields shown to be masked. A job that ran without errors is not enough.

7. Set policies to run after refresh

Salesforce's documentation says that "in production orgs, create and manage policies that run automatically in target sandboxes after a refresh." Jobs can also run manually or on a schedule. Set the trigger for each sandbox to match how often it is refreshed, then refresh one sandbox and confirm the policy ran.

8. Uninstall the managed package

The knowledge article says that once policies have been transitioned, you can uninstall the package, and it links Salesforce's instructions for uninstalling a first-generation managed package. Keep your inventory and pilot results. They are your record that masking was rebuilt and checked.

A timeline for the eight weeks left

There are 57 days from 4 November to 31 December. This split is our recommendation, not Salesforce's:

• By 13 November: steps 1 to 3. Inventory finished, licence answer in writing, access assigned.
• Rest of November: steps 4 to 6. Policies rebuilt and one sandbox validated.
• By mid-December: step 7 on every sandbox, ahead of any year-end change freeze.
• Before 31 December: step 8, once nothing depends on the old package.

If you are looking at alternatives

Policies have to be rebuilt whichever tool you choose. Switching tools now costs about the same as staying. If you want to compare, Cloud Compliance's DataMasker is a Salesforce-native managed package on AppExchange. It masks data in place inside your org and runs its rules on sandbox refresh. It can be triggered by REST API from DevOps tools such as Copado and Gearset, mutes automations while it masks, and updates Remote Site Settings after a refresh. It does masking only and does not generate synthetic seed data. Neither does Data Mask & Seed yet: Salesforce's retirement article lists synthetic data generation and seeding among the enhancements "coming soon". Our Data Mask end-of-service page compares the three options side by side.

If you would like to see DataMasker run against one of your sandboxes during step 6, book a demo.

Sources

• Salesforce Help, knowledge article 005299299, "Data Mask Managed Package Retirement", updated 5 October 2026 (read 3 November 2026)
• Salesforce Help, "Secure Your Sandbox Data with Salesforce Data Mask (Legacy)" (read 3 November 2026)
• Salesforce Help, "Protect Sensitive Data with Data Mask & Seed" (read 3 November 2026)
• Salesforce Help, "Data Mask & Seed Requirements and Limitations" (read 3 November 2026)
• Salesforce, Cloud Data Security pricing page (read 3 November 2026)
• Cloud Compliance, Sandbox DataMasker product page and Data Mask end-of-service page

This article is general information, not legal advice.