Default field values don't populate during a CRM migration because defaults are a record-creation convenience, not a data backfill. A default value fires (at most) when a new record is created without a value for that field — and behavior varies by platform and load tool. Nothing in Salesforce or HubSpot reads your field settings and back-fills thousands of imported rows with the values your team expects. If the business rule is "every active client record should say Client, have a client-since date, and be flagged as primary," that rule has to live in the migration itself: as a column in the load file, a value in the field-mapping document, or a post-load update. This matters for any team mid-migration who has opened the new system, run a spot check, and found supposedly "defaulted" fields empty — the fix is mapping work, not a settings change.
Because "default" means three different things, and only one of them is a platform feature.
The first is the platform default: the default value configured on a field (for example, a checkbox that defaults to checked, or a picklist with a default selection). That default exists to speed up a human creating one record at a time. Whether it fires during a bulk data load depends on the platform, the API, and the tool — and in the cases that matter most, the load file's contents win. If your file carries an explicit value (including a legacy placeholder like "Unknown" or an empty string that the tool interprets literally), the platform default never gets a chance.
The second is the derived default: a value that should be computed from other data. "Client-since date equals the date the relationship started." "Contact type is Client if there's an active agreement, Prospect otherwise." No platform setting can express these — they were never configured anywhere. They existed as shared understanding on the legacy team, and migrations expose how much of a data model lives in people's heads.
The third is the constant default: every migrated record in scope gets the same value — a branch assignment, a record type, a "Primary" flag. These are trivial to apply, but only if someone writes them down. When a client opens the new system and finds them blank, the cause is almost always the same: the value was discussed in a meeting but never made it into the mapping document, so no one loaded it.
| Kind of "default" | Example | Does it apply to migrated records? | Where it must live |
|---|---|---|---|
| Platform field default | Checkbox defaults to checked; picklist default value | Inconsistent — depends on platform, API, and whether the load file supplies a value | Field configuration — but never rely on it for loads |
| Derived business rule | "Client-since date = relationship start date" | No — the platform has no way to know the rule | A formula or lookup in the mapping document, computed into the load file |
| Constant value for the migration set | "Branch = Central for every record in this file" | No — nobody told the system | A constant column in the load file |
| Automation-set value | Flow or workflow stamps a value on create | Only if the automation fires on bulk insert — many are filtered to UI creates or specific sources | Automation design review before load day |
The pattern: three of the four kinds require deliberate migration work. Assuming the platform will handle it is how empty fields reach production.
The field-mapping document (the crosswalk) is the migration's single source of truth, and defaults belong in it as first-class rows. For every target field, the crosswalk answers: what source field feeds it, what transformation applies, and what value applies when the source is empty or the rule says so. A practical mapping row includes:
Two habits make this stick. First, walk the crosswalk field by field with the business owner before any load, and ask of every field: "what should this say if the legacy system never captured it?" That question surfaces the derived and constant defaults while they're still cheap. Second, treat the sign-off on that document as a real gate — it's the same discipline described in a design sign-off before UAT: decisions locked in writing, open items tracked, nothing left to assumption.
Even with a perfect mapping document, the tools have behaviors worth knowing:
#N/A convention, with checkbox fields as a noted exception). If your expectation was "empty cell becomes the default," the tool never promised that.Assume some defaults were missed and go looking for them before users do. For every field that carries a default rule, run an exception report in the new system: records where the field is blank, or where it holds the placeholder, segmented by the populations the rule covers. A "Primary flag unchecked" report on a record set that should be 100% primary is a thirty-second check that saves a painful discovery later.
Then spot-check by hand. Pick a small, known sample — a handful of households or accounts the business knows well — and open each record. Automated reconciliation confirms counts; human eyes confirm meaning. The client's question in a sandbox review ("shouldn't these say Client?") is exactly the audit step working as intended — the goal is for that question to come up in the sandbox, not after go-live.
Finally, close the loop in writing. Each missed default gets logged, fixed with a targeted update load, and checked off. That's cleaner than broad re-runs, which risk overwriting fields that were correct.
If a migration is ahead of you: insist on a field-mapping document that names a default rule for every target field, review it with the business before the first test load, and budget a sandbox review cycle whose whole job is to hunt for missing values. If a migration is behind you and fields are empty: resist bulk-fixing everything at once — report first, fix the fields that drive process and reporting, and document the rules so the next integration or import doesn't repeat the miss.
Vantage Point runs CRM migrations as a mapping-first discipline: every engagement includes a field crosswalk with explicit default and transformation rules, sandbox load cycles, and post-load exception reporting before anything reaches production. That work sits inside system integration and data migration services, alongside Salesforce implementation and advisory and HubSpot consulting when the target platform needs its own data model decisions. For teams already live, managed services cover the cleanup pass — finding and repairing the values that didn't make the trip.
Vantage Point is a Salesforce and HubSpot Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Not reliably. Default values are designed for record creation, and bulk load tools insert exactly what the file contains — Salesforce's Data Import Wizard even treats empty cells as "no change" instructions rather than blanks. Plan defaults into the load file itself instead of depending on field settings.
Most often because the "default" was a business rule, not a platform setting — for example, "active relationships should say Client" — and no system was ever configured to apply it. The fix is to write the rule into the field-mapping document and apply it with a targeted update load.
No — an import sets only the properties included as columns in the file. HubSpot's default property values apply to records created manually, not to imported rows. Add a column with the intended value to every import file that needs it.
Add it as a column in the load file with the same value on every row, and record the rule in the mapping document so future loads repeat it. This is the standard way to handle values like branch assignments, record types, and primary-record flags.
Generally no. Flows and workflows are often disabled or bypassed during bulk loads for performance and predictability, and many are scoped to specific creation sources anyway. Migration values should come from the load file; automation should handle records created after go-live.
Run exception reports for each defaulted field (blank or placeholder values), then manually review a small sample of well-known records to confirm meaning, not just counts. Fix misses with targeted update loads, and log each fix so nothing is re-broken later.