Own implementation cost: Salesforce Backup & Recover licences, services and quotes
Own is now sold as Salesforce Backup & Recover, alongside Archive and Data Mask & Seed. There is no list price, so the quote is built from your orgs, add-ons and the work needed to prove a restore.
Platform & ArchitectureBackup is the Salesforce purchase nobody hopes to use. The licence earns its keep on the worst day of the year, when a bad data load, a runaway Flow or an integration user with too much access has overwritten thousands of records and someone senior asks how quickly they can be put back. That is why the implementation cost of Own, now sold by Salesforce as Backup & Recover, is less about installing software and more about proving, before that day comes, that a restore actually works on your org.
This guide covers what you pay Salesforce, what the implementation is made of, how to get quotes you can compare, and the costs that tend to turn up after the first order form is signed.
What you pay Salesforce for Backup & Recover
Salesforce completed its purchase of Own on 18 November 2024, and the flagship product changed its name. In Salesforce's words: "Own Recover, ranked the #1 Enterprise SaaS Backup by G2, is now Salesforce Backup & Recover." The other Own products moved across under the same data resilience banner: Archive, for moving inactive records out of production storage, and Data Mask & Seed, for building masked, realistic test data in sandboxes.
There is no public list price. As at October 2026, the Salesforce Backup & Recover page puts it plainly: "Pricing varies based on each customer's individual needs." It goes on to say the sales team will tailor a package to your requirements. So this is a quote-only product, priced in US dollars or your local currency on the order form, and the useful question is what that package is assembled from.
The product page gives you the levers even without the numbers. Backup & Recover lets you configure backups for any number of production orgs or sandboxes, so the count of environments you protect belongs on the quote. Salesforce also states: "Continuous Data Protection (CDP) is a separate add-on capability to Salesforce Backup & Recover." Continuous Data Protection captures every change rather than relying on interval snapshots, which matters for fast-moving objects such as Cases or Orders, and it is bought on top of the base product. Archive and Data Mask & Seed are separate products again. Salesforce also offers protection for ServiceNow and Microsoft Dynamics CRM instances, which is relevant if your resilience policy covers more than one system. Finally, there is Backup & Recover Next, the newer native offering with automated daily backups, which Salesforce says is available with FedRAMP High compliance in select regions. If both appear in a proposal, ask which one you are being sold and why.
| Component | How it is sold, as at October 2026 | What to tell Salesforce so the quote is specific |
|---|---|---|
| Backup & Recover | Quote-only, packaged by Salesforce sales | Production orgs and sandboxes in scope, data and file volumes, retention you need |
| Continuous Data Protection | Separate add-on to Backup & Recover | Which objects change fast enough to need change-level capture |
| Archive | Separate product, quote-only | Record and file volumes you want out of production, and who needs to read them later |
| Data Mask & Seed | Separate product, quote-only | Sandboxes you refresh, sensitive fields, how often developers need fresh data |
| ServiceNow or Dynamics coverage | Quoted on request | Non-Salesforce instances your policy requires you to protect |
What the $1.9 billion figure is, and is not
Search for Own costs and one number keeps appearing. Salesforce agreed to buy Own for about $1.9 billion in cash, net of the shares it already held. That is the price of a company with thousands of customers. It tells you nothing about the licence for your org, and nothing about the services effort to configure backup for two production orgs and a handful of sandboxes. If a proposal or an article anchors on that number, set it aside. Your cost is set by your environments, your retention policy, the add-ons you choose and the restore work you need proven.
What a Backup & Recover implementation is made of
Backup projects are small by Salesforce standards, which is exactly why they get under-scoped. Turning on a daily backup is a configuration task. Agreeing what "recovered" means, and showing that the business can get there inside the time it expects, is the real project. A sound quote breaks into work packages like these.
| Work package | What it covers | Effort depends on |
|---|---|---|
| Discovery and policy | Recovery point and recovery time targets, retention period, legal hold, regulator expectations | How many owners must agree, and whether a policy already exists |
| Scope and connection | Orgs and sandboxes to protect, the backup user and its permissions, objects, metadata and files in or out | Number of orgs, managed packages, field-level security gaps on the backup user |
| Monitoring and alerts | Thresholds for unusual deletes or changes per object, who is alerted and what they do next | Number of critical objects, maturity of your incident process |
| Restore runbooks | Written steps for single records, whole objects and parent-child hierarchies | Depth of custom object relationships, automation that fires on insert |
| Timed restore test | A restore into a sandbox, checked against the source, with the elapsed time recorded | Data volume, Flows and triggers that must be held back during restore |
| Archive design, if bought | Which records leave production, the criteria, how users and auditors retrieve them | Storage pressure, reporting that still needs archived records |
| Data Mask & Seed, if bought | Masking rules per sensitive field, seeding templates per sandbox | Count of sensitive fields, sandbox refresh cadence |
| Handover | Admin training, alert ownership, a recurring restore drill | Team turnover, whether a managed service runs it afterwards |
The timed restore test is the package that separates a real quote from a licence resale. Restoring records is not like restoring a file. When thousands of Cases come back into production, every record-triggered Flow, Apex trigger, validation rule and duplicate rule sees them as fresh inserts or updates. A Flow that emails the customer on Case creation will email them again. An integration that pushes new Accounts to your ERP may push them twice. A validation rule added last quarter may reject records that were valid when they were backed up. Somebody has to design how automation is held back during a restore, usually with a custom permission or a setting that every Flow and trigger checks, and then test it. That is most of the engineering in a backup project, and it is specific to your org.
Relationships are the other source of effort. Backup & Recover is designed to restore records with their relationships intact, but your runbook still needs to say which parent comes back first, what happens to child records created since the backup, and who checks the result. Write those down for the three or four objects that would hurt most: usually Account, Opportunity, Case and whatever custom object carries your billing or service data. For each one, record how long the restore took in the test, how many records failed and why, and what a person had to do by hand afterwards. Those three numbers are what you take to the business when they ask whether the recovery target is realistic.
What pushes the effort up or down
Several things make a Backup & Recover project larger than the brochure suggests.
- More than one production org. Each org has its own users, automation and restore quirks, and each needs its own runbook and test.
- Heavy use of files and attachments. Large file volumes lengthen backup windows and restore tests, and they are usually where retention arguments start.
- Managed packages. Package objects need to be in scope, and some package automation cannot be switched off by your admins during a restore.
- Shield Platform Encryption. If you encrypt fields, confirm with Salesforce how encrypted data is handled in backup and restore, and include key management in the policy work.
- An outgoing backup tool. Moving from another vendor, or from the weekly export, means deciding what happens to the history you already hold.
- Regulated data. Financial services, health and government buyers often need written evidence of restore tests, which adds documentation and sign-off time.
What makes it smaller is equally clear: one org, a retention policy someone has already written, admins who know where the automation lives, and a sandbox you can restore into without a fight over who is using it.
The cost of doing nothing instead
Every Salesforce org already has a free option of sorts. The Data Export service in Setup produces a weekly or monthly set of CSV files, and many organisations treat that as their backup. It is worth pricing honestly, because it is the baseline your Backup & Recover quote is competing with.
The export costs nothing to switch on. The cost arrives on the day you need it. The files hold record data, not a point-in-time view you can browse, compare or restore from with relationships intact. Restoring means an admin or developer working out which rows changed, rebuilding parent and child links by hand, loading them back with Data Loader or a script, and dealing with the same automation problem described above, all under pressure. Metadata is not in the export at all. And a weekly export means up to a week of changes may simply be gone.
So the comparison is not "licence versus free". It is the licence plus a modest implementation, against an unbudgeted, unplanned recovery effort with an uncertain result. For a small org with low change volume, a disciplined export and a written restore procedure may be a defensible choice. For an org where Cases, Orders or billing records change all day, the gap between a weekly CSV and a tested restore is the thing you are actually buying.
Getting quotes you can compare
Two quotes are involved: the licence from Salesforce and the services from a partner or Salesforce Professional Services. Ask the same questions of each so you can line them up.
For the licence, ask Salesforce to name the unit the order form is measured in, list every org and sandbox the package covers, state the retention included, and show Continuous Data Protection, Archive and Data Mask & Seed as separate lines even if you decline them. Ask whether restores carry any volume or frequency limit, which support tier is included, and whether Backup & Recover or Backup & Recover Next is being proposed. If you also run ServiceNow or Dynamics, ask whether protecting them changes the package.
For the services, ask for the deliverables by name. How many restore runbooks? Which objects get a timed restore test, and in which sandbox? Who designs the automation bypass, and is it tested with your real Flows rather than a demo org? Who owns alerts on the day after go-live? A quote that lists "configure backup" and "training" with no restore test has priced the easy half of the job.
Costs that sit outside the first quote
These are the items that most often appear later.
- A sandbox to restore into. A meaningful restore test needs a sandbox with realistic volumes. Depending on your edition, a Full Copy sandbox may be an extra Salesforce purchase, and a Partial Copy may not hold enough data to prove anything.
- Overlap with the outgoing tool. If your current backup vendor holds history you are legally required to keep, you may need to run both for a period or export that history somewhere safe. Plan the licence overlap before you give notice.
- Salesforce data storage. If Archive is deferred, production storage keeps growing, and additional Salesforce data storage is its own line item.
- Admin time. Alerts are only useful if someone reads them. Budget a few hours a week for triage at first, falling as thresholds settle.
- Recurring restore drills. A restore tested once at go-live is a historical fact. A quarterly or half-yearly drill keeps it true as automation changes.
- Masking for sandboxes. If developers work with copies of production personal information, Australian Privacy Principle 11 obligations still apply to those copies. Data Mask & Seed, or an equivalent process, has a cost either way.
- Support. Check whether the support included with the package matches the response time your recovery targets assume. A four-hour recovery target with next-business-day support does not add up.
Where to go next
For what the products now do, read Own and Salesforce Backup & Recover, and for the history of the acquisition, what happened to Own. The licence side is covered in more detail in Own licence cost. If you are deciding whether to stay with your current backup approach, should I migrate from Own weighs the options, and integrating Own with Salesforce covers the connection and permissions work. When you are ready to compare partners, hiring an Own Salesforce partner lists the questions worth asking. If you want backup monitoring and restore drills run for you after go-live, that is part of our managed services.
The short version: ask Salesforce for a package that lists every org and every add-on separately, ask your partner for a timed restore test with your real automation, and do not let a company acquisition price stand in for either.



