A team changes its export tool and imports last week's contact CSV. The addresses arrive, but the next operator cannot tell which inputs were checked, which returned no match, or which stopped before lookup. Reprocessing the whole list feels safer than trusting an incomplete history.
The migration needs a progress ledger alongside the business data. Preserve what happened to every input, then map that history into the destination's actual capabilities. This guide proposes an application-side design with fictional examples. It does not report a tool migration, vendor benchmark or new contact-research run.
Separate three things you may need to retain
A business export contains the rows another team wants to use. A progress ledger explains attempts and outcomes. A product-specific backup may retain workspace state needed by that product. Treat these as different artifacts rather than assuming one file can replace all three.
Inspect the documented export and restore behavior of the specific route before planning a move. A CSV import may have no place for prior job identifiers or provider labels. If so, keep the ledger in an approved sidecar store and link it to the imported identities.
Do not call a successful file import a complete workflow migration. The receiving operator still needs to locate the relevant account, understand the input scope and reconcile unfinished work. No amount of tidy column formatting establishes those things.
Preserve outcomes for every input
Start from the submitted input list, not just the rows with an address. Give each input a stable key and retain its association with the source batch. Record attempts separately if the same input was processed more than once.
A completed lookup with no match is a different outcome from a request that never finished. An unknown transport result needs investigation before retrying; a missing address alone cannot tell you whether the provider ran the job.
A fictional attempt record could be:
{
"input_batch": "fictional-batch-09",
"input_record_id": "item-18",
"identity_key": "reviewed-identity-18",
"attempt_id": "attempt-18-a",
"provider_job_ref": "recorded-job-reference",
"execution_state": "completed",
"lookup_outcome": "no_match",
"provider_status_raw": "example-provider-label",
"observed_at": "2026-11-01T14:00:00Z"
}
The label is deliberately illustrative. Preserve the real provider's status before mapping it to a local outcome. A destination should not reinterpret a missing label as a successful verification.
Write a status mapping before importing history
List the source states and decide how the destination will represent them. If the destination cannot express a state, preserve it outside the tool and make the limitation visible to the operator.
| Source evidence | Migration treatment | Next action |
|---|---|---|
| Completed lookup, accepted candidate | Retain candidate, source and review decision | Inspect validity for the new use |
| Completed lookup, no match | Keep an explicit no-match outcome | Retry only under a documented policy |
| Access prevented the check | Preserve the access issue | Assigned account owner reviews access |
| Submission result is uncertain | Retain the original job reference | Inspect the existing job first |
| No attempt recorded | Mark as not started | Consider for the next approved batch |
These treatments are proposed rules, not built-in features of a named product. Keep “unknown” available when the source evidence is insufficient. Forcing every row into completed or failed can destroy the distinction the ledger exists to preserve.
Reconcile the move with counts and samples
Count distinct submitted identities, attempt records and candidates independently. One identity may have multiple attempts or candidate addresses. Those extra rows should not inflate the count of people completed.
Compare the original set of input keys with the migrated ledger. Investigate keys that disappeared or appeared without explanation. Also inspect samples from each status group, including no match and uncertain submission, rather than checking only populated email rows.
For a small pilot, ask a second operator to find one accepted result, one no-match outcome and one unresolved attempt. They should be able to explain the next action using the retained evidence. This is an acceptance procedure to perform in the real environment, not a claim that it has been tested here.
Build the next batch from reviewed unfinished work
After migration, create an explicit next-input artifact. Do not select every row with a blank email field: that would combine untouched inputs, completed misses and interrupted attempts.
Inspect unresolved provider jobs before resubmitting them. Keep the old and new job references linked when a retry is justified. If employer context or identity evidence changes, retain that revision with the new attempt so the result difference is explainable.
Assign an owner for session renewal and exception review. Moving data does not establish that the destination has the required account access, runtime capacity or provider configuration. Verify those dependencies through the approved route before scheduling real work.
BrowserAct's workflow-switching comparison provides the host, workspace and provider context. The progress ledger adds a portable explanation of the work: what was requested, what actually finished, what remains uncertain and why the next batch contains the rows it does.
Top comments (0)