Preview-first restore: the missing pattern in identity DR

Every identity DR vendor has converged on the same promise: recover your Okta org in minutes, not hours. We say it too. It's on the homepage. It's the first thing buyers ask about on a demo call. And it's table stakes now.

Here's the question that should follow it, and almost never does: what if the restore makes things worse?

The failure mode nobody markets against

Imagine an admin restoring a backup at 2:00 PM after a misconfiguration at 1:55 PM. The backup is from this morning. The restore engine reads the snapshot, applies it to the live tenant, and the tenant returns to its 8:00 AM state. Fast. Clean. Resolved.

Except.

Between 8:00 AM and 1:55 PM, a teammate added three engineers to a production app group during an onboarding push. None of that is in the backup. The restore quietly removes them. Nobody notices until those engineers can't deploy at 4:00 PM and the on-call rotation lights up.

Worse case: the snapshot has stale entitlements. A user was deactivated last week for cause. The backup predates the deactivation. The restore re-grants their group memberships and re-activates the assignment. Now a deprovisioned account has access to a production app and nobody knows because the operator was looking at the system status, not the delta.

This isn't theoretical. It's the predictable consequence of running any "fast restore" without a preview layer. The faster the restore, the faster you ship the second incident.

What preview-first actually means

Preview-first restore inverts the default. Instead of "click restore, then verify," it's "see the diff, choose what applies, then commit."

In practice:

• Dry-run diff. Before a single write hits Okta, the operator sees every field-level change the restore would make. Group X loses 4 members. App Y gains 2 assignments. Policy Z reverts from 30-min session to 8-hour session.
• Per-resource selection. The operator can deselect any resource or sub-change. "Restore the policy, skip the group memberships, leave the user assignments alone." Granular by default.
• Conflict warnings. If a resource has been modified since the snapshot was taken, surface it. The operator decides whether the snapshot version or the live version wins, per resource.
• Sourced-user warnings. If a snapshot would re-create or re-assign a user that's been deactivated, deleted, or moved to a different sourced state, flag it loudly. Restoring an old user record over a deprovisioning event is the worst-case incident.
• Audit trail. Who clicked restore. Which snapshot. Which resources were included. Which were skipped. What the diff said at the moment of commit. Searchable, exportable, signed.

When you put all of that together, restore stops being a one-button gamble and becomes an operator decision with full context.

Why this isn't standard

Building a fast restore is mostly a backend problem. Parallelize writes, batch API calls, retry intelligently, and you can rebuild a tenant in a few minutes. The infrastructure is finite. You ship a benchmark, put it on the homepage, and move on.

Building preview-first is a product problem and a UX problem. You need a real diff engine that understands every resource type the IdP supports, including the ones with embedded references (group rules that target other groups, policies that reference network zones, apps that reference auth servers). You need a UI that lets a tired operator at 2 AM read 600 changes and decide which 12 they actually want. You need backend write paths that can take a partial selection and apply only that, atomically.

That's months of work the buyer doesn't see in a benchmark. So most vendors don't lead with it. They lead with speed because speed demos well.

But speed without preview is just velocity into a wall.

What this looks like in Butterfly

Every restore in Butterfly is preview-first. Not "preview is an optional toggle." Default. The operator picks a snapshot, the system computes the diff against the live tenant, and the operator gets a per-resource view of every change before any write happens.

• Resource-level checkboxes. Include this group, skip that app, defer the policy.
• Conflict callouts when the live tenant has drifted since the snapshot.
• Sourced-user and deactivation warnings inline with the resource that triggers them.
• A signed audit record of what the operator saw and what they chose.

You can walk through a live restore preview in the dashboard — the diff view, the per-resource controls, the warnings. It's the same UI an operator uses during an actual incident.

The TLDR for buyers

"Minutes to recover" is parity. Every serious vendor in the category will get there if they aren't there already.

"Preview before you commit" is the differentiator. It's what separates a restore that resolves the incident from a restore that creates the next one. When you're evaluating an identity DR platform, ask:

• Can the operator see every field-level change before any write happens?
• Can the operator deselect individual resources or sub-changes?
• Does the platform flag conflicts and sourced-user issues inline, not in a post-restore report?
• Is the diff the operator saw at the moment of commit captured in the audit trail?

If any of those is no, the vendor is selling you a faster way to fail.

For a head-to-head against the closest competitor that markets preview, we keep a Butterfly vs Acsense comparison updated with the per-feature differences.

The next incident you respond to isn't going to be solved by another 30 seconds of restore speed. It's going to be solved by knowing exactly what you're about to change before you change it.