Dual Running: The Controlled Transition
A guide for operational staff supporting the period where the legacy system and Salesforce run side-by-side — what the overnight pipeline does, what it doesn't do, and how to manage the transition safely until the old system is switched off.
What is Dual Running?
After the initial Go-Live load, Salesforce is live and being used — but the legacy system hasn't been switched off yet. During this dual running period, both systems operate in parallel:
Legacy System (Source)
Staff continue entering data here. This system is the source of truth — its data takes precedence over Salesforce during the transition. Changes here are synced to Salesforce each night.
Salesforce (Destination)
Staff may also work in Salesforce directly. These changes are detected and flagged — but the legacy system remains master, so source changes overwrite conflicting Salesforce edits during the nightly sync.
Goal: Keep the two systems in sync until the business is confident Salesforce is correct and complete, at which point the legacy system is switched off and Salesforce becomes the sole master.
How the Overnight Pipeline Supports Dual Running
Each night, the unattended pipeline runs three processes that keep the systems aligned and provide full visibility:
Delta-Only Load (Source → Salesforce)
Only records modified in the legacy system since the last sync are loaded to Salesforce — not the full table. This makes each night's sync fast and predictable. A watermark timestamp tracks the last successful sync point.
Dual-Side Change Detection
The pipeline queries Salesforce for records modified since the last watermark (using the SystemModstamp field) and compares them against the source changes. This identifies what changed on each side overnight.
Reconciliation Report
A report classifying every changed record into three categories — source-only, Salesforce-only, and conflict. Saved to the Document Library and emailed to admins each morning for review.
What This Covers
Source changes synced overnight
Any record modified in the legacy system is upserted to Salesforce each night — existing records are updated by SF ID, new records are inserted.
Salesforce edits detected
If staff edit records directly in Salesforce, the pipeline detects these via the SystemModstamp field and flags them in the reconciliation report.
Conflicts identified
Where both systems modified the same record, the conflict is logged with both modification timestamps. The source (legacy) wins — the Salesforce edit is overwritten — but the conflict is visible for review.
Full audit trail
Every night's load report and reconciliation report is saved to the Document Library — searchable, permanent, and accessible from any machine.
Watermark tracking
The last sync timestamp is stored on the job. If a sync fails, the watermark isn't advanced — the next run picks up from the same point, so no changes are missed.
Pre-load metadata toggle
Validation rules, Apex triggers, and flows can be automatically disabled before the load and restored after — preventing load failures from automation that hasn't been updated yet.
What This Does NOT Cover
It is critical to understand the boundaries. This is a one-directional sync (source → Salesforce) with detection — not a bi-directional merge. The following are not handled:
Salesforce changes are NOT written back to the legacy system
The pipeline detects SF-only changes and flags them, but does not push them back to the source. The legacy system remains the master — if staff need those changes in the legacy system, they must re-enter them manually.
No real-time sync
The pipeline runs overnight on a schedule. Changes made during the day in either system are not visible in the other until the next night's sync completes.
Conflicts are resolved in favour of the source — automatically
When both sides changed the same record, the source overwrites the Salesforce edit. The SF edit is lost. The reconciliation report shows which records were affected, but the resolution is automatic (source wins). Staff must review the report to identify any legitimate SF edits that were overwritten.
No record deletion sync
If a record is deleted in the legacy system, it is NOT automatically deleted from Salesforce. The delta load only handles inserts and updates. Deletion handling must be managed separately.
Requires a modified-date column in the source
Delta loading relies on a timestamp column in the legacy table (e.g. last_modified_date). If the source table doesn't have one, the system falls back to a full table scan — which is slower but still works.
Salesforce SystemModstamp only
SF change detection uses the SystemModstamp field, which captures all modifications (API, UI, automation). However, if automation runs during the load window itself, those changes may not be captured in the reconciliation (they're excluded to avoid counting our own load).
Capability Matrix
Reading the Reconciliation Report
Each morning, a reconciliation report is saved to the Document Library and emailed to admins. Here's how to interpret it:
Source-Only Changes
Records modified in the legacy system that were NOT also modified in Salesforce. These were synced to Salesforce overnight — no action needed. This is the expected, healthy state.
Action: No action — these are the records the pipeline correctly synced.
SF-Only Changes (User Edits)
Records modified directly in Salesforce but NOT in the legacy system. These are edits made by staff working in Salesforce. They are flagged because the legacy system is still master — if the corresponding source record is later modified, the Salesforce edit will be overwritten on the next sync.
Action: Review these records. If the SF edit is legitimate and should be preserved, re-enter it in the legacy system so it becomes the source of truth. Otherwise, it will be overwritten when the source record next changes.
Conflicts (Both Changed)
Records modified in BOTH systems since the last sync. The source (legacy) wins — the Salesforce edit has been overwritten. The conflict is logged with both timestamps so you can see what happened.
Action: Review immediately. Identify which SF edits were lost. If any were critical, re-enter them in the legacy system. Track whether conflicts are recurring for specific records — this may indicate staff are working in the wrong system.
Daily Operational Checklist
Each Morning
- 1Check the admin email for the overnight load report and reconciliation report.
- 2Open the Document Library to review the reconciliation report — check for conflicts (red) and SF-only changes (amber).
- 3If conflicts are present, identify which Salesforce edits were overwritten. Re-enter any critical ones in the legacy system.
- 4Review SF-only changes — confirm whether staff should be working in Salesforce or the legacy system. Communicate if the wrong system is being used.
- 5If the load failed (red status in the report), check the error details and the Table Loader page for batch-level errors. The watermark is NOT advanced on failure — the next run will retry from the same point.
Transition Phases
The dual running period follows a phased approach. Each phase has clear entry criteria and exit criteria:
Phase 1: Go-Live
Initial full load completed. Salesforce is live. Legacy system remains master. Delta sync + reconciliation begin running nightly.
Exit criteria:
Zero conflicts for 3+ consecutive nights. All SF-only changes reviewed and resolved.
Phase 2: Dual Running
Both systems in active use. Nightly delta sync keeps them aligned. Reconciliation reports reviewed daily. SF-only edits monitored and discouraged.
Exit criteria:
Consistently low conflict count. Staff predominantly working in Salesforce. Legacy system changes reducing to near-zero.
Phase 3: Switch-Off
Legacy system switched to read-only or decommissioned. Salesforce becomes sole master. Delta sync and reconciliation can be discontinued. The watermark is no longer needed.
Exit criteria:
Legacy system decommissioned. Salesforce is the single source of truth.
Who Does What
Operational Staff
- Continue working in the legacy system as the master
- Minimise direct edits in Salesforce during dual running
- Re-enter any critical SF-only edits into the legacy system
Admin / Reviewer
- Review reconciliation report each morning
- Investigate conflicts and SF-only changes
- Decide when conflict count is low enough to proceed to switch-off
- Monitor the Document Library for report history
Migration Consultant
- Configure the Table Load Job with source_modified_column and reconciliation_enabled
- Set up the overnight schedule via Task Scheduler
- Tune the watermark and field mappings as needed
- Advise on transition phase exit criteria
Where to Find Things
Reconciliation Reports
Document Library — filter by 'Reconciliation Report' type
Load Reports
Document Library — filter by 'Sync Report' type
Batch-Level Errors
Salesforce Table Loader — click 'Review Batches' on the job
Scheduled Tasks
Task Scheduler — view and manage the overnight schedule
Pipeline Overview
Unattended Workflow page — the full overnight pipeline diagram
Sync Dashboard
Real-time sync status and governance actions
Controlled, Visible, Auditable
The dual running period is the highest-risk phase of any migration. The overnight pipeline ensures every change is tracked, every conflict is logged, and every report is archived — so the business can transition with confidence.