Spreadsheet workflow migration map before you choose a tool

Silence is not a delete decision

When nobody can confirm why a field exists, mark it as hold and name the person who must resolve it. A hold means “do not remove yet,” not “keep forever.” Record where the field appears, whether it contains stored values and which process decision may depend on it. If the destination cannot accept the field, that remains an unresolved conversion or retention decision.

Record keep, convert, or hold

Use keep when the source value can remain meaningful in the target design. Use convert when its format, permitted values or destination representation must change. Use hold when approval, purpose or target handling is unresolved. Add an approver and an unresolved-decision note to every hold. For wider context, see the CRM integration overview, but keep the field decisions in this map.

Name the decision the sheet is making

Write one plain-English statement for each recurring decision. Hypothetical examples include deciding who owns a record, whether a row is ready for review or whether an exception needs another action. For each decision, record the source fields used, the person who decides and what indicates completion. Business stakeholders should participate in deciding what data moves and whether the migrated data meets operational needs (Microsoft Learn, Suggested workflow for a complex data migration, accessed October 2026).

Mark what the export drops

RFC 4180 describes CSV as text records made of fields for exchanging tabular data (IETF RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files, accessed October 2026). That transport does not by itself document spreadsheet formulas, manual sign-offs, access decisions or recurring checks. Mark formulas, unstored fallbacks, manual sign-offs, access decisions and recurring checks separately from exported values. An exception note or message text stored in a cell remains a value, so do not assume every exception or message disappears. The Google Sheets tool page provides related spreadsheet context.

What the cell stores

Inventory the literal value and its source column. If it is an identifier, label what it identifies. If it is an exception note or message text, preserve that meaning in the value category. Inspect the proposed target field type and validation rule before deciding that it can load (HubSpot Knowledge Base, Format import files, accessed October 2026).

What the team still has to do

Record manual review, fallback decisions, sign-off, access checks and evidence collection as separate work. A formula belongs under formula replacement. A person who decides an exception belongs under exception owner. A person who approves the migration belongs under approver. Blank entries show what must be settled before selection.

Convert values before loading

Describe the conversion as a rule another person can review. State the current representation, intended target representation and permitted values. Keep it unresolved if the candidate system's field type and validation behavior have not been inspected.

Hypothetical example, not a tested migration or customer result. Approval and destination evidence remain unresolved until the candidate is inspected.

Keep the source identifier

Record the source unique identifier and destination match field together. The migration design should retain a source unique identifier and separate successful and failed outcomes so records can be matched and retried (Microsoft Learn, Suggested workflow for a complex data migration, accessed October 2026).

HubSpot documents one behavior

For a HubSpot candidate, record the documented behavior in that candidate's worksheet. Keep blank, clear, unknown and not applicable as distinct business meanings. If an existing value must be cleared, do not assume a blank performs that action in this documented case.

Confirm the rule in the destination

For every other candidate, leave the blank rule unresolved until current documentation or a controlled destination check establishes it. Write the expected behavior before checking. Record whether the operation should create, update, clear, ignore or reject a value.

Separate failed rows from the load

Keep successful and failed outcomes distinct. HubSpot exposes post-import evidence that includes row outcomes, created and updated record counts, error impact and downloadable error rows (HubSpot Knowledge Base, Review and troubleshoot record import errors, accessed October 2026). Treat that as a HubSpot-specific evidence option, not a promise about every system.

Name the state and the next owner

Define an exception state and assign an exception owner. A missing required value, renamed sheet, invalid lookup or missing column can be used as a hypothetical planning prompt, but the cited sources do not define those states for every product. The team must decide the names and resolution path. Reprocessing starts only after the cause, owner and retry rule are recorded.

Carry a stable owner identifier

Record the source owner identifier, its target representation and the person responsible for validating the mapping. Names alone may not establish identity. Show the identifier the destination expects and any cases that cannot yet be assigned.

Verify reassignment and access after an owner leaves

No cited source decides who should own a historical record after the original employee leaves, or who should be able to open it. Treat both as destination-specific decisions. Record the reassignment rule, access check, person performing it and retained evidence. Do not infer access merely because the owner field loaded.

Match on the source identifier

Compare the retained source unique identifier with the destination match field. Record whether the destination reports a create, update or failure. If the destination does not expose enough evidence, mark the result as ambiguous and assign it for review.

Hold ambiguous outcomes before retrying

No cited source proves that retrying an ambiguous row cannot duplicate a successful record. Hold it until someone verifies the destination outcome. Write the retry rule, exception owner and required evidence. The provider evidence request guide provides a related method for separating claims from observed results.

Pick evidence the destination can produce

Ask each candidate which evidence it exposes, then confirm that in current documentation or a controlled review. AWS DMS documents source-to-target validation that can compare corresponding rows, verify their data and report mismatches (Amazon Web Services, AWS DMS data validation, accessed October 2026). Use that only as a database migration example unless the candidate can produce equivalent evidence.

Write the acceptance decision

For every evidence item, record the expected result, approver, observed result and unresolved decision. Leave observed result blank until evidence exists. Acceptance is the named stakeholder decision that the available evidence meets the stated operational need, not merely that a file loaded.

Reconcile counts before you call it done

Migration planning should include audit and reconciliation, while failed records should be logged, resolved and reprocessed (Microsoft Learn, Suggested workflow for a complex data migration, accessed October 2026). In HubSpot, documented import evidence includes created and updated counts plus error information (HubSpot Knowledge Base, Review and troubleshoot record import errors, accessed October 2026).

Name the system that owns the next edit

No cited source decides which system should own an update during a phased migration. Add phased authority to the worksheet and leave it unresolved until an accountable owner signs it. Name the system of authority for that stage and the person who can change the decision.

Keep values and identifiers separate from behavior

Map stored values and identifiers to target fields. Record formula replacement, relationships, automation checks and dynamic behavior in separate entries. Do not mark them complete merely because values imported. Their acceptance evidence must describe the behavior checked and result observed.

Verify trigger behavior before any test load

Trigger behavior is destination-specific. Salesforce's Data Import Wizard asks whether workflow rules and processes should run when imported records meet their criteria, and selecting “add new and update existing records” can fire workflows that add new objects, while selecting “update existing records” does not (Salesforce Help, Import Data with the Data Import Wizard, accessed October 2026).

Before a test load or retry, record trigger controls and the outbound-message check. Hold the load when trigger behavior is unknown. This guide recommends the hold as a safety rule for the worksheet. It does not claim that every platform offers the same control.

Complete source decisions first

Start with process decision, source column, field disposition and source unique identifier. Add known business meanings for blanks, duplicates, formulas, relationships, exceptions and phased authority. Keep uncertainty explicit. The first automation checklist can help frame scope and acceptance before migration.

Fill destination checks per candidate system

For each candidate, add target field types, validation behavior, owner model, blank behavior, load errors, trigger controls, access checks and acceptance evidence. Do not copy one vendor's documented behavior into another candidate's row.

Choose the tool last

Compare candidates against completed source decisions and unresolved checks. The tool decision follows the map because the map contains the process requirements the tool must meet.

Hypothetical example, not a tested migration or customer result:

If you have a defined migration project and want to describe its scope, use the /request form. This does not promise an introduction to a directory provider.

Which duplicate wins

No cited source settles whether the newest, most complete or operationally active record should win. Record the business decision in the duplicate rule field. Also record the source unique identifier, destination match field, approver and evidence required to show the rule was applied.

What replaces a formula

No cited source defines a universal formula replacement. RFC 4180 describes CSV records and fields (IETF RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files, accessed October 2026). That format alone does not define a replacement for spreadsheet behavior. Put the proposal in the formula replacement field, then specify the target field, trigger or rule involved and required acceptance evidence. Leave it unresolved until the replacement has an owner and a candidate-specific check.

What must the sandbox review show

No cited source provides one universal sandbox script. Choose evidence the destination can produce: stakeholder review, staging counts, an import error file or source-to-target row comparison. Keep each limit visible. HubSpot documents import outcomes and error rows, while AWS DMS documents a database row-comparison pattern; neither proves what every candidate sandbox will show.