ETL (Extract, Transform, Load)
The pattern of pulling data from a source, reshaping it and loading it into a target.
ETL describes the three phases of moving data between systems: extract from the source, transform it to match the destination's model and rules, then load it. In CRM migrations, the transform step carries the risk — field mapping, picklist translation, date formats, deduplication rules and encoding all live there. Anything unmapped at transform time is either lost or dumped into a notes field, which is why the mapping document is signed before any load begins.
Delta sync
A follow-up load that captures records created or changed since the main migration.
A delta sync moves only the records created or modified since the historical snapshot was taken. It is what allows a large migration to run over days while the source system stays in use: the bulk load happens in the background, and a short delta run at cutover catches the difference. Delta syncs depend on reliable last-modified timestamps in the source system — where those are missing, the migration plan needs a different strategy.
Reconciliation report
The post-migration document proving source and destination counts agree.
A reconciliation report compares source and destination record counts, field fill rates and association counts for every object, and explains every variance. Expected variances (excluded test records, agreed skips) are listed with the rule that produced them; unexplained variances are treated as defects. It is the artefact that lets a business shut down a legacy system with confidence rather than paying for it indefinitely.
HubSpot migration →
Deduplication
Identifying and merging records that represent the same person or company.
Deduplication finds records representing the same entity — matched on email, domain, normalised name or fuzzy similarity — and merges them while preserving associations, activity history and the correct owner. It should be run as its own controlled phase, never simultaneously with a migration, because merging changes counts and makes reconciliation impossible. Every merge should be logged so a mistaken merge can be traced.
CRM data cleanup →
Data governance
The rules and ownership that keep a CRM clean after it has been cleaned.
Data governance is the set of documented rules about who can create properties, what values are permitted, which fields are required at each stage, how imports are approved and who reviews quality. Without it, a cleanup project decays within two quarters. Effective governance is small: a short standards document, validation on the handful of fields that drive routing and reporting, and one named owner.
Field mapping
The signed document defining how every source field lands in the destination.
A field mapping document lists every source field with its destination property, data type, transformation rule and handling for empty or unrecognised values, including an exhaustive enumeration of picklist values. It is the contract for a migration: when someone asks months later why a field looks different, the answer is a row in the document. Unmapped fields are an explicit decision, not an accident discovered later.
Hypercare
The intensive support period immediately after go-live.
Hypercare is the heightened support window straight after launch — typically 30 days — with daily monitoring, rapid fixes, data reconciliation checks and open office hours for questions. It exists because the first two weeks of real use surface issues no test plan predicts. Skipping hypercare is how a technically successful implementation becomes a system nobody trusts.
Our process →
Sandbox
A separate HubSpot environment for testing changes safely.
A sandbox is a non-production HubSpot portal used to test migrations, automation changes and integrations before they touch live data. Available on Enterprise tiers, it is the difference between discovering a mapping error in a diff report and discovering it in front of the sales team. Sandboxes do not carry all production data by default, so test datasets need deliberate construction.
API rate limit
The cap on how many API requests an integration may make in a window.
HubSpot enforces per-app and per-portal request limits, commonly around 100 requests per ten seconds for standard tiers, plus daily caps. Integrations that ignore them fail silently or partially, leaving data half-synced. Robust integrations batch requests, retry with exponential backoff, queue work during spikes and log every failure so gaps are visible rather than assumed.
Data enrichment
Adding third-party firmographic or contact data to existing records.
Enrichment appends data you did not collect — company size, industry, technologies, revenue band, job seniority — from a third-party provider. It shortens forms and improves scoring and segmentation, but coverage and accuracy vary sharply by region and company size. Enrich only the fields that drive a decision, and audit accuracy on a sample before trusting enriched fields in routing.
Sandbox testing plan
The scripted checks run in a test portal before changes go live.
A testing plan lists what will be verified before a change ships: record counts, property fill rates, association integrity, workflow outcomes for representative records, integration round-trips and a period of real usage by actual end users. Written as a checklist with named owners, it converts 'we tested it' into evidence someone can review.