How to Roll Back a Failed Migration After Go-Live

It's 9 AM on Monday. Friday's cutover looked clean — the sample migration passed, signoff was given, the source system was set to read-only. Now your CFO is asking why two weeks of invoices are missing, your support team can't find tickets created over the weekend, and a senior AE is threatening to quit because their pipeline is gone.

You have a decision to make: fix forward, or roll back.

Here's what most migration vendors won't tell you: rollback is almost always harder than the original migration, often impossible after 72 hours, and the decision must be made fast. Every hour you spend deliberating, net-new data is accumulating in the target system, integrations are writing to it, and your rollback window is shrinking.

Before going further, one critical distinction. Migration rollback means returning operational ownership to the source system and reconciling any net-new data created after cutover. Target cleanup means deleting imported data from the target. These are not the same job. If a vendor says it has an "undo" or "rollback" feature, read the fine print — Import2's Undo Migration cleans migrated results from the target, and Help Desk Migration's rollback deletes selected entities from the target. Both are useful for cleanup. Neither reverse-syncs live data that users created in the target after go-live.

If your migration hasn't fully failed yet — data is partially missing, scripts stalled, but you haven't fully cut over — start with our Helpdesk Migration Failed? The Engineer's Rescue Guide. That covers recovery. This post covers what happens when recovery isn't enough and you need to reverse the cutover entirely.

The 72-Hour Rule: Why Rollback Windows Close Fast

A migration rollback plan has a half-life. Viability degrades hour by hour, not day by day.

Hour 0–24: The Golden Window

Your source system is still in read-only mode. The target has minimal net-new data — maybe a few dozen tickets or records created since cutover. Rollback at this stage is mostly operational: re-enable writes on the source, redirect integrations, export and reconcile the small delta of net-new target data. This is the cheapest, fastest rollback you will ever get.

Even in this best case, platform limits matter. A Salesforce reverse sync can burn through API quota fast — Enterprise Edition starts at 100,000 API requests per rolling 24-hour period, and sustained overuse triggers REQUEST_LIMIT_EXCEEDED. Zendesk's incremental export endpoints are capped at 10 requests per minute, so even extracting weekend changes can take longer than panicked stakeholders expect.

Hour 24–72: The Delta Problem

Net-new data is now accumulating in the target. Users have created records, agents have replied to tickets, sales reps have updated pipeline stages. Rolling back now means reverse-migrating that delta back to the source system — which often hits the exact same edge cases (field mapping conflicts, ID collisions, API rate limits) that broke the original migration. You are now doing a second migration under pressure.

Hour 72–168: Grace Periods Expire

This is where rollback transitions from difficult to near-impossible. Source-system contracts may have been downgraded or canceled. Sandbox environments refresh on their own schedules. API tokens get revoked. Integrations have fully re-pointed to the new system and are generating data with no representation in the source. Rollback at this stage is not a rollback — it is a re-implementation.

Beyond One Week

After a week of active use, rolling back is rarely cheaper or safer than fixing forward. The cost of reversing a week's worth of live business data typically exceeds the cost of cleaning and correcting the target system in place. The target is now the system of record, however flawed it might be.

The Triage Checklist: Fix Forward or Roll Back?

Run through this checklist in the first 60 minutes. Work through it with your team before making any irreversible decision.

1. What is missing vs. what is wrong?

Missing data is recoverable. A batch of tickets that didn't migrate can be re-imported via delta sync. Wrong data is far worse — mismapped fields, incorrect statuses, corrupted parent-child relationships mean users are already acting on bad information, triggering incorrect automations, and polluting reporting. If "Closed Won" deals show as "Open" or ticket priorities are inverted, every hour of use compounds the damage.

2. Is the source system still accessible?

Confirm this before anything else:

• Source-system contracts haven't been canceled or downgraded
• Sandbox sessions haven't expired
• API tokens haven't been revoked
• The source database hasn't been archived or purged

If the source is gone, rollback is off the table regardless of anything else on this list.

3. What is the net-new data volume in the target?

Pull a record count segmented by creation timestamp and object type. 200 new tickets in 48 hours is recoverable via manual entry or a simple script. 20,000 new records across 14 custom objects is a massive engineering project. The delta size determines which rollback pattern is viable.

4. Are integrations writing to the new system?

Slack notifications, Zapier flows, billing webhooks, marketing automation, calendar syncs, CTI, email routing, forms. Every integration now writing to the target needs to be identified, paused, and reversed before rollback. Miss one, and you will have data flowing into a system you are trying to abandon.

5. Has finance closed anything in the new system?

If month-end has been booked in the new platform — journal entries posted, sub-ledgers reconciled — rollback now creates audit and GAAP compliance issues. NetSuite warns that reopening a closed period can automatically reopen later closed periods and force checklist work to be redone. Stop and call your controller or accountant before touching anything technical.

6. What is the business cost per hour?

Quantify it: revenue per hour of downtime, support SLA breach costs, regulatory exposure, customer churn risk. This number determines your budget, your urgency, and whether emergency engineering spend is justified.

7. Who is the incident commander?

One person owns the clock, the status message, and the go/no-go call. Everyone else supplies facts.

The First-Hour Escalation Template

Do not hide the problem. Send this to the executive team within the first hour:

Subject: Migration incident — rollback decision due by [time]
 
We have confirmed a post-go-live data integrity issue affecting [systems/teams].
 
Current status:
- Source system availability: [readable/writable/not confirmed]
- Target net-new data since cutover: [count by object]
- Business impact: [revenue/support/finance/compliance]
- Immediate action taken: [writes paused/integrations paused/users notified]
 
Decision window:
We will recommend either FIX FORWARD or ROLLBACK by [time].
Until then, assume system state is unstable and avoid approving downstream process changes.
 
Incident commander: [name]
Technical lead: [name]
Business owner: [name]
Next update: [time]

The Three Rollback Patterns

Every rollback falls into one of three patterns based on elapsed time and net-new data volume.

Pattern A: Full Reversal (< 24 Hours)

Best case. The source system is intact and the delta is small.

Steps:

1. Block all user access to the target system.
2. Re-enable write access on the source system.
3. Redirect all integrations (email routing, webhooks, API endpoints) back to the source.
4. Export all net-new data created in the target since cutover.
5. Manually reconcile or script-import that delta into the source.
6. Run a validation pass comparing source record counts against the pre-migration baseline.
7. Communicate the reversal to all users with clear instructions.
8. Schedule a postmortem within 48 hours.

Who needs to be on the call: Ops lead, the engineer who ran the original migration, one representative from each team that uses the system daily.

What kills it: The source system has already been decommissioned, archived, or its contract canceled. Always confirm source accessibility first. The mistake many teams make is skipping the delta export because "we're only rolling back a day." One day of invoices, ticket replies, candidate movement, or SLA events still matters.

Pattern B: Reverse Delta Sync (24–72 Hours)

You are now doing a mini-migration in the opposite direction. The original migration's field mappings have to be inverted — same schema, opposite direction.

This is where the difference between a self-serve tool and engineer-led migration work becomes stark. Automated tools that advertise "undo" or "rollback" features typically just delete the records they imported into the target. Import2's undo feature removes migrated records from the target but does not capture or reverse-sync any net-new data created since cutover. Help Desk Migration's rollback works the same way — it deletes imported entities, not reverse-sync them. Useful for cleanup. Not for operational recovery.

A true reverse delta sync requires:

1. Snapshot the target's current state — every record created or modified since cutover.
2. Build reverse field mappings — the original migration mapped Source Field A → Target Field B; now you need Target Field B → Source Field A, accounting for any transformations applied during the original migration.
3. Validate that source-system IDs haven't been reused — if the source auto-increments IDs and any new records were created before it was set to read-only, you risk ID collisions.
4. Push the delta back to the source using UPSERT logic based on external IDs or preserved custom field keys, not native platform IDs. Zendesk ticket IDs are automatically assigned on creation, so the target's native ticket ID cannot be replayed back into the source — you need an immutable join key like external_id.
5. Replay audit logs to capture status changes, assignments, and workflow triggers that occurred in the target.

Timeline: 3–7 days depending on data volume and platform complexity.

Who needs to be on the call: A migration engineer with API-level access to both systems, plus a data steward who understands the business logic behind field mappings.

What kills it: The original migration had lossy transformations — for example, concatenating two source fields into one target field. You cannot un-concatenate data without the original source records. If those are gone, the reverse mapping is permanently degraded. This is where having an engineer-led migration partner matters. A self-serve wizard cannot reason about ID reuse, join keys, replay order, or audit-safe reversals.

Pattern C: Parallel-Run Fix-Forward (> 72 Hours)

When the rollback window has closed, stop pretending otherwise. Put the source system back in front of users, fence writes in the target, and repair the target in controlled batches while both environments exist.

Steps:

1. Re-enable the source system for all end-users.
2. Set up a dual-write layer — new data enters both systems simultaneously, or enters the source and syncs to the target on a schedule.
3. Dedicate an engineering team to cleaning and correcting the target data.
4. Run validation reports comparing both systems weekly.
5. When the target reaches data parity and passes QA, schedule a second cutover.

Timeline: 4–8 weeks for the parallel period, then a second cutover weekend.

Who needs to be on the call: Executive sponsor (this is expensive), migration engineering team, a project manager tracking the dual-system state.

What kills it: Data divergence. If the dual-write layer is not airtight, the two systems slowly drift apart, and you end up needing a third migration to reconcile them. The rule: one system owns live work, the other is being repaired. If both own live work, you are creating a second incident. Define a hard commit date for the second cutover and enforce it.

Platform-Specific Rollback Constraints

Every vendor wants you to migrate in. None of them build tools to help you migrate out. Here is what breaks when rolling back major platforms.

Salesforce

Salesforce's official guidance separates three concepts that teams routinely conflate: deployment rollback (metadata can roll back on error or before commit), full-org restore via Backup & Recover for widespread corruption or loss, and post-go-live operational reversal. Your post-cutover problem is usually none of those clean cases. There is no native "undo" button for a data migration.

Certain metadata — Approval Processes, complex flow triggers — must be manually reverted because they don't exist cleanly in the deployment API.

API limits compound the problem. Enterprise Edition starts at 100,000 API requests per rolling 24-hour period, plus 1,000 per user license. Bulk API helps (each 10K-record batch counts as one call), but you are still constrained to 15,000 batches per day. A poorly sized reverse sync can exhaust this while normal business operations are still running.

Sandbox refresh timing matters. If your rollback plan depends on a sandbox copy of pre-migration data, know that sandbox refresh intervals vary by type. If the sandbox has already been refreshed post-migration, your pre-migration snapshot is gone.

Zendesk

Ticket ID conflicts are the primary headache. Zendesk auto-generates unique ticket IDs on creation. Original ticket IDs from a source system must be stored in custom fields during migration. A reverse sync has to match against those custom fields, not native IDs — adding complexity to every query and import. If you are extracting deltas through incremental exports, plan around the 10-requests-per-minute ceiling.

Deleted users cannot be restored. Zendesk's official documentation confirms that deleted end users cannot be recovered — not by admins, not by Zendesk support. The soft-delete period is 30 days, but during that window the user can only be permanently deleted, not restored. If your migration process deleted or merged users as part of cutover cleanup, those users cannot be recreated with their original ticket associations intact.

End-user identity merging is one-way. If users were merged during migration, unmerging them requires manually recreating the separated identities and reassociating their tickets — a process that does not scale.

HubSpot

Lifecycle stage corruption. HubSpot's lifecycle stages are designed to only move forward. If a migration incorrectly set contacts to "Customer" or "Opportunity," you cannot simply revert them to "Lead." You must first clear the lifecycle stage property entirely, then set it to the correct value — but clearing the property also resets all "Became a [stage] date" timestamps, which corrupts historical reporting permanently.

Contact deduplication during reverse-sync. HubSpot deduplicates contacts by email address and companies by domain. If you sync records back from a target system and those contacts already exist in the source HubSpot instance, the import will update existing records rather than creating new ones — potentially overwriting source data with target data. The Record ID property can supersede other identifiers during import, adding another matching hazard.

Workflow re-enrollment. Any workflows paused for the migration need to be individually re-enabled and tested. Workflows that triggered based on lifecycle stage changes may fire incorrectly on contacts whose stages were corrupted and then corrected. HubSpot workflows do not automatically re-enroll records unless re-enrollment is explicitly configured — a reverse sync can silently fail to replay the workflow state users expect, or worse, trigger a mass email blast to your customer base from the sudden influx of "updated" contacts.

NetSuite and Business Central

If the target system is financial, the rollback decision is partly an accounting decision. NetSuite warns that reopening a closed period can automatically reopen later closed periods and force checklist work to be redone. Business Central prefers corrective documents and audit-preserving reversals over hard deletion — its reversing-entry shortcut does not apply to every posted transaction.

Sub-ledger rollback (AP, AR, inventory) must happen before the GL is touched. Finance must approve any technical work before engineering begins. This is not optional. Reversing posted transactions in an ERP without finance team involvement creates reconciliation nightmares that persist for quarters.

Workday and Greenhouse

Active hiring creates irreversible state. If candidates have been moved through interview stages, offers extended, or requisitions closed in the target ATS since cutover, those actions generated candidate-facing communications. Rolling back the system does not un-send those emails or un-schedule those interviews.

In Greenhouse specifically, candidate profiles cannot be un-merged, auto-merge does not evaluate profiles created via the Candidate Ingestion or Harvest APIs, and unreject is not supported in bulk. Once hiring activity has continued for days, a blanket rollback can create as much candidate confusion as the bad cutover itself.

Candidate communication history is platform-bound. Messages sent through the target ATS will not exist in the source. A rollback creates a gap in communication history that recruiters must manually bridge.

How to Avoid Needing This Post

Save this section for a colleague having a good week. Here is how you avoid being the person reading this at 3 AM.

Run a shadow period before decommissioning the source. Keep the source system live and accessible (even read-only) for at least two weeks after cutover. Do not cancel contracts, revoke API tokens, or archive data until you have confirmed the migration is clean. Our zero downtime migration approach is built around this principle.

Define kill-switch criteria before go-live. Write down — in advance — the specific conditions under which you would roll back. "More than X% of users report missing data within Y hours" is a rollback trigger. "Executive feels uneasy" is not. Get signoff on these criteria from the exec sponsor before cutover weekend.

Validate with full-volume test migrations, not subsets. A 10% sample migration that passes does not mean the full migration will. Edge cases cluster in the data you didn't test. Test full, complex parent-child relationships in a staging environment before go-live.

Keep the original migration scripts and mappings versioned. If you need to build a reverse sync, you will need the exact field mappings, transformation logic, and ID maps from the original migration. If these are not version-controlled, a rollback becomes archaeology.

Preserve an immutable external ID on every migrated object. Before go-live, confirm that every record carries an external ID that can serve as a join key between source and target. Without this, reverse delta sync is exponentially harder.

Test one reverse-delta exercise in sandbox. Before you declare rollback "covered" in your runbook, actually execute a small reverse-delta sync in a sandbox environment. Discovering that your reverse mapping breaks at runtime is cheaper during testing than during an incident.

The hard truth: rollback is almost always harder than the original move. The good news — most failed cutovers are still recoverable when somebody takes control early, freezes the blast radius, and chooses a pattern instead of improvising.