What does a HubSpot implementation involve?
A HubSpot implementation designs and builds the portal around how your business sells: objects and properties, deal pipelines with exit criteria, lifecycle stages, permissions, forms, workflows and dashboards. It works in four stages: audit what you have, design the structure, build and test in a sandbox, then train the team and document everything.
This checklist is for the ops lead or founder at a B2B company starting HubSpot, or restarting it after a quick setup that never held. It follows the four stages we use on our HubSpot implementations.
- 01 AuditPortal, data, integrations, process
- 02 DesignApproved on paper first
- 03 Build and testSandbox first, in dependency order
- 04 Train and documentEach role, plus SOPs and the data model
Why do HubSpot implementations go wrong?
Most go wrong the same way: the portal is configured quickly, never architected, and never documented. Defaults are left in place, fields are added as people ask for them, and nobody writes down how anything works. Within a year the data is unreliable and the team works around the CRM instead of in it.
The fix is to make the design decisions before the build, and to write them down. Every item below is a decision, not a click.
Stage 1: What should you audit before building?
Audit four things: the current portal or system, the data, the integrations, and the sales process itself. Write down what works, what is broken, and what is costing time. That document becomes the brief for the design, and it stops the new build from repeating old mistakes.
- Portal or current CRM: objects, properties, pipelines, workflows and users in use today.
- Data: volume, duplicates, missing fields, and what has to migrate.
- Integrations: every system that will read from or write to HubSpot.
- Process: how a lead becomes a customer in practice, step by step, including the exceptions.
Stage 2: What should you design before you build?
Design the data model, pipelines, lifecycle stages and permissions on paper first, then get them approved. Changing a design costs minutes; changing a live portal with data in it costs days. The design should answer what each object holds, how records move, and who can do what.
Objects and custom properties
Decide which standard objects you will use (contacts, companies, deals, tickets) and whether you need custom objects. Build a property catalog: name, type, allowed values, owner and purpose for every custom property. Reuse before creating.
Deal pipelines and stages with exit criteria
One pipeline per genuinely different sales motion, not per team. Each stage gets an exit criterion that can be checked in HubSpot, such as "proposal sent" or "budget confirmed", so stages reflect reality.
Lifecycle stages and lead statuses
Write entry and exit criteria for each lifecycle stage and keep lead status for day-to-day sales work. See HubSpot lifecycle stages explained.
Teams and permissions
Define teams and the permissions for each role: permission sets on Enterprise, HubSpot's permission templates on Professional. Limit super admins, exports and deletion rights from day one; it is far harder to take access away later.
Stage 3: How should you build and test?
Build in a sandbox or test environment first, in dependency order: properties, then pipelines, then forms and lists, then workflows and sequences, then dashboards. Test each piece with realistic sample records before deploying. Dashboards come last because they depend on everything underneath them.
- Forms map to the right properties and set a lifecycle stage.
- Routing and task workflows tested with sample records, including exceptions.
- Imports and integrations tested on a small batch first.
- Dashboards checked against known numbers before anyone relies on them.
Want the architecture designed before anything is built?
Stage 4: What should training and documentation cover?
Train each role on its daily work in your own portal, then hand over written documentation: SOPs, the data model, automation logic, the integration map and a permission matrix. The test of a good handover is that your team can run, change and explain the system without the people who built it.
The HubSpot implementation checklist
These expand the six checkpoints in our CRM architecture blueprint.
Key takeaway: Implementation quality is decided in the design stage. Make the decisions, write them down, and build to the document.
Frequently asked questions
How long does a HubSpot implementation take?
On our projects, roughly three to eight weeks from audit to handover, depending on data, hubs and integrations. The stage-by-stage timeline and what makes it longer are in How long does a HubSpot implementation take?
Do we need a partner, or can we implement HubSpot ourselves?
Small teams with a simple sales process can implement HubSpot themselves using a checklist like this one. A partner helps most when you are migrating data, connecting several systems, running more than one pipeline, or rebuilding a portal that grew without a design.
What should be documented at handover?
The data model (objects, associations and the property catalog), pipeline stages with exit criteria, lifecycle and lead status definitions, a permission matrix, the automation logic, the integration map, and SOPs for daily work. Your team should be able to run and change the system without the people who built it.
Can we implement one hub first and add others later?
Yes, as long as the data model is designed for where you are going. Define shared objects, lifecycle stages and ownership rules up front, then add hubs onto that structure instead of bolting each one on separately.
Sources
HubSpot documentation behind the feature and tier notes above, checked October 2026. HubSpot changes features and tiers often, so check your own portal too.