Salesforce platform change
Salesforce Data Mask reaches end of service on December 31, 2026
The Data Mask managed package is being retired — not masking itself. Salesforce says support already ended on 9 July 2026 and the package goes read-only on 31 December. Here is what is actually changing, what Salesforce recommends instead, and what your options are if you mask sandbox data today.
“The Data Mask managed package reaches end of service on December 31, 2026. After this date, Salesforce no longer supports the Data Mask managed package. To continue protecting your sandbox data, start working with Data Mask & Seed before December 31, 2026.”
— Salesforce Help: Secure Your Sandbox Data with Salesforce Data Mask (Legacy)
“Salesforce ended support for the existing Data Mask managed package on July 9, 2026. Additionally, the package will be read-only starting December 31, 2026.”
— Salesforce Help: Data Mask Managed Package End of Support, updated 4 August 2026
Salesforce documentation last checked .
What is actually changing
Salesforce Data Mask was delivered as a managed package that you installed into your production org and ran against your sandboxes. That package is what reaches end of service — and Salesforce’s own knowledge article puts it more sharply than its product page: support ended on 9 July 2026, and the package goes read-only on 31 December 2026. Salesforce has since renamed its documentation to “Salesforce Data Mask (Legacy)” and points customers at Data Mask & Seed, which is built into the platform instead of installed as a package.
So this is not a capability being withdrawn. It is a re-platforming, and the practical consequence for you is that the masking configuration you built has to be re-created and re-validated in something else before the deadline.
That re-validation is the part worth taking seriously. A masking rule that quietly stops matching a field does not throw an error — it just leaves real customer data sitting in a sandbox that a dozen people can open. If you are migrating masking configuration, the deliverable is not “the jobs run”, it is “these named fields are demonstrably masked”.
Your three options
We sell one of these. We have tried to describe all three fairly — you can check every claim about the Salesforce products against the links above.
Move to Data Mask & Seed
The path Salesforce recommends, and the lowest-surprise option if you are happy with how Data Mask worked. It is native, it adds seeding, and it stays inside the Salesforce relationship you already have. Ask your AE what your existing Data Mask entitlement converts to.
Salesforce's recommendationEvaluate an AppExchange alternative
Reasonable specifically because you have to redo the configuration work regardless. The switching cost you would normally weigh against changing tools is a cost you are paying either way, which makes this the one moment where a real comparison is close to free.
Worth doing now, not in 2027Do nothing yet
Defensible only if you know how much masking you actually have. If nobody can currently say which fields are masked in which sandboxes, that is not a decision to defer — it is an open compliance question you happen to have a deadline attached to.
Only with eyes openData Mask (Legacy) vs Data Mask & Seed vs DataMasker
Salesforce columns reflect Salesforce's published documentation. Neither Salesforce product has publicly listed pricing, so those cells say so rather than guess.
| Data Mask (Legacy) | Data Mask & Seed | CC DataMasker | |
|---|---|---|---|
| Status after 31 Dec 2026 | Read-only — and unsupported since 9 July 2026 | Salesforce's current masking product | Unaffected |
| How it is delivered | Managed package installed in your production org | Built into the Salesforce platform | Managed package from AppExchange |
| Where masking runs | Inside your Salesforce org | Inside your Salesforce org | Inside your Salesforce org |
| Licensing | Salesforce Data Mask managed package (Legacy) add-on licence | Salesforce Data Mask add-on licence | Per-org subscription |
| Published pricing | Not publicly listed | Not publicly listed | Listed on our pricing page |
| Run on sandbox refresh | Yes | Yes — manual, scheduled, or automatically on create/refresh | Yes |
| Reusable masking configuration | Data Mask configurations | Reusable masking policies | Reusable masking rules |
| Custom replacement values | Custom libraries | Built-in and custom replacement value libraries | Built-in and custom patterns |
| Filter which records get masked | Limited | Yes — per object | Yes — per object and field |
| Preserves production record IDs | Yes — masks in place | Yes — masks in place | Yes — masks in place |
| Synthetic data seeding | No | Yes — seeding is part of the product | No — masking only, by design |
| Runs from a DevOps pipeline | Limited | See Salesforce documentation | Yes — Copado and other CI/CD tools |
A migration plan that fits the time left
- Now
Find out whether you are affected
Check whether the Data Mask managed package is installed in your production org, and which sandboxes actually run masking jobs against it. Teams are frequently surprised here — masking is often set up once and never revisited.
- Next
Write down what your current masking actually does
Export your existing configurations: which objects, which fields, which replacement values. This is the artefact you migrate, and it is also the checklist you validate against afterwards. Do this before you touch any new tool.
- Then
Pilot the replacement on one sandbox
Whichever product you choose, run it against a single non-critical sandbox and diff the result against your written configuration. Confirm field by field that what should be masked is masked.
- Before 31 Dec 2026
Cut over and decommission
Move the remaining sandboxes, confirm masking runs on refresh, and remove the legacy package once nothing depends on it. Leaving an unsupported package installed is its own audit finding.
Data Mask end of service: common questions
The Data Mask managed package is — and it is further along than most teams realise. Salesforce's knowledge article states that support for the managed package ended on July 9, 2026, and that it becomes read-only on December 31, 2026. Salesforce's product documentation still describes December 31, 2026 as its end of service. Masking itself is not going away — Salesforce has replaced the managed package with Data Mask & Seed, which is built into the platform rather than installed as a package.
It already has. Salesforce's knowledge article on the Data Mask managed package end of support, updated August 4, 2026, states: “Salesforce ended support for the existing Data Mask managed package on July 9, 2026. Additionally, the package will be read-only starting December 31, 2026.” Salesforce's older Data Mask (Legacy) product page still says the package “reaches end of service on December 31, 2026.” Read the two together: unsupported now, read-only from January 1, 2027.
Data Mask & Seed. Salesforce's own guidance is to start working with Data Mask & Seed before December 31, 2026. It provides reusable masking policies, built-in and custom replacement value libraries, masking jobs that run manually, on a schedule, or automatically when a sandbox is created or refreshed, per-object record filtering, and job monitoring.
Nothing is deleted on that date, but the managed package goes read-only — you can see existing masking configurations, not run or change them — and it has already been unsupported since July 9, 2026: no fixes, no support, and no assurance it keeps working through future Salesforce releases. Treat December 31 as the date to have migrated by, not a switch that flips. Any team relying on masked sandboxes for a compliance obligation should not be depending on unsupported software.
Salesforce's documentation states Data Mask & Seed is available in Professional, Enterprise, Unlimited, and Developer Editions with the Salesforce Data Mask add-on licence. The legacy managed package also required an add-on licence. Salesforce does not publish pricing for either, so what you pay is a conversation with your Salesforce account executive — ask specifically whether your existing entitlement carries across.
It depends entirely on how much masking configuration you have. The work is re-creating your masking rules in the new product and re-validating that the right fields are actually being masked — not a data migration. The re-validation is the part teams underestimate: a masking rule that silently stops matching a field is worse than no masking at all, because nobody notices.
It is a reasonable one, because you have to redo the configuration work either way. That is the honest case for evaluating options now rather than in 2027 — the switching cost you would normally weigh against a change is a cost you are paying regardless. Whether you land on Data Mask & Seed or something else, do the evaluation while there is still time to run a real pilot.
A Salesforce-native masking application from Cloud Compliance, installed from AppExchange. It masks real production data in place inside your Salesforce org, preserving record IDs, with per-object and per-field rules and DevOps pipeline support. It is a masking tool — it does not do synthetic data seeding, which is a genuine difference from Data Mask & Seed.
Working out what to do before December 2026?
We will walk your masking configuration with you and tell you plainly whether moving to Data Mask & Seed or to DataMasker is the better fit for your org. No obligation to switch.