Quick Answer
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.
TL;DR
- Why defaults go missing: CRM default values apply when users create records, not to rows inserted by a migration — and most "defaults" teams expect are actually business rules nobody configured anywhere.
- The reliable home for defaults: the field-mapping crosswalk. Every expected default gets a target column and a value (or formula) in the load file.
- Loader behavior differs: Salesforce's Data Import Wizard treats empty cells as "no change," and nulling a value takes a deliberate marker — empty is not the same as blank.
- Audit, don't assume: post-load exception reports (records where Field X is blank) catch missed defaults before users do.
- How Vantage Point helps: CRM data migration services include mapping documents, default-value rules, and post-load validation.
Why don't default values carry over in a CRM migration?
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.
Where do defaults actually live during a migration?
| 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.
How do you build defaults into the field mapping?
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:
- Target field and its data type (including whether it's a required field).
- Source field(s), or "constant" / "derived" when no source exists.
- Default rule in plain language: "if Source Type is empty and the record has an active agreement flag, set Contact Type to Client; otherwise Prospect."
- Owner — the person who confirms the rule, so it doesn't live in someone's head.
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.
What load mechanics surprise teams?
Even with a perfect mapping document, the tools have behaviors worth knowing:
- Empty cells are not blanks. Salesforce's own guidance for the Data Import Wizard is explicit: the wizard ignores empty cells and treats them as "no change" instructions — so on an update, an empty cell won't clear an existing value, and on an insert it won't write anything at all. Deliberately nulling a field requires a specific marker (the documented
#N/Aconvention, with checkbox fields as a noted exception). If your expectation was "empty cell becomes the default," the tool never promised that. - HubSpot imports write exactly what the file contains. HubSpot's import tool maps columns to properties one to one — a property with no column in the file simply isn't set on the imported records. HubSpot does support default property values for records created by hand, but an import is not a manual create; if the column isn't there, the value isn't either.
- Automation may or may not fire. Flows and workflows that stamp values on record creation can be scoped to specific sources, profiles, or record types, and teams routinely (and correctly) disable automation during bulk loads to keep the load fast and predictable. If a value was "automatic" in the old system, confirm whether anything still sets it after the migration.
- Required fields mask the problem. A required field forces the loader to supply something, and under deadline pressure that something is often a placeholder. Months later, reporting quietly fills up with "Unknown" and "TBD." Defaults deserve the same design care as the fields users notice.
How do you audit defaults after the load?
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.
What should businesses do next?
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.
How Vantage Point Helps
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.
Planning a migration, or fixing one?
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.
Frequently Asked Questions
Do Salesforce default field values apply during a data import?
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.
Why are fields empty after our CRM migration even though they had defaults?
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.
Does HubSpot apply default property values on import?
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.
How do you set a constant value for every record in a migration?
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.
Should automation set default values during a migration load?
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.
How do you check for missing default values after a migration?
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.
