What HubSpot onboarding actually includes, and what it does not
This is the most common and most expensive misunderstanding in the platform, so it is worth being precise.
When you buy a paid tier, HubSpot requires onboarding and charges for it. What you receive is guidance: a consultant who runs sessions with your team, explains how the features work, advises on configuration, and answers questions on a schedule. It is genuinely good, and it is training.
What it does not include is someone building it. Your data is not migrated for you. Your integrations are not developed for you. Your lifecycle stages, property architecture, pipelines, and reporting are advised on rather than constructed. At the end of the engagement the sessions stop, whether or not the portal does what you bought it for.
The result is a predictable pattern. Onboarding completes on time, a partial setup exists, the person who attended the sessions has other responsibilities, and twelve months later the company is paying enterprise pricing for a contact database and email tool.
Implementation is the separate job of building the thing. If you have already paid for onboarding, that is not wasted, your team understands the platform better than they would otherwise. It simply is not the same purchase.
What a real implementation covers
Ordered roughly as we do it, because the order matters more than any individual step.
Data first, always. Deduplication, deciding which system is authoritative for each field, and designing the property architecture before anything is imported. Skipping this is the single most common cause of a portal nobody trusts a year later, because every automation and report built afterwards inherits the mess and multiplies it.
Object and lifecycle architecture. Which objects exist, how they associate, and what each lifecycle stage actually means, defined so that marketing and sales agree. “MQL” meaning two different things to two teams is the root of most reporting disputes we get called in to settle.
Pipelines and process. Deal stages that match how your sales team really sells rather than an idealised funnel, with exit criteria specific enough that two reps would stage the same deal identically.
Automation, once the above is stable. Lead routing, scoring, notifications, and nurture. Built after the data model rather than alongside it, because workflows written against properties that later change is how you end up with automations nobody dares turn off.
Integrations. The website, ad platforms, product, and billing. This is where implementations usually exceed what the interface can do, and where having engineers rather than only consultants changes what is possible.
Reporting. Dashboards built from the data model rather than assembled hopefully from whatever fields exist, plus attribution wired so a deal closing in fourteen months still points back to what created it.
Handover. Documentation and training so your team can run it. An implementation only your agency understands is a dependency, not an asset.
Migrating to HubSpot from another CRM
Migrations fail on the parts nobody scoped, and they are the same parts every time.
Associations, not records. Moving contacts and companies is straightforward. Preserving which contact belongs to which deal, which activity belongs to which record, and which historical owner had which account is the hard part, and it is what makes the data useful afterwards.
History. Notes, emails, calls, and stage changes. Losing them technically succeeds at the migration and destroys the reason sales trusted the old system.
Custom fields and objects, which in a mature Salesforce instance can number in the hundreds, most of them unused. A migration is the right moment to decide what does not come across, and that is a business decision that needs someone senior to make it.
The parallel run. Both systems live for a period, with a defined rollback. Cutting over on a Friday and hoping is how migrations become incidents. This is usually the longest phase and the one clients most want to shorten.
We migrate from Salesforce, Pipedrive, Zoho, Dynamics, and from spreadsheets, which is more common than vendors like to admit and often the cleanest starting point.
Auditing a portal that has drifted
Most portals more than two years old need an audit rather than a rebuild, and the audit is cheap relative to what it usually finds.
What we look at: duplicate records and the rules that created them, properties that are unused, redundant, or mean the same thing under three names, workflows that are active but orphaned, lifecycle stage definitions against how they are actually applied, integration health and where sync is silently failing, permissions and data access, and reporting accuracy checked against source systems rather than against other dashboards.
The output is a list ordered by what it costs you, not by what is easiest to fix. In most portals a small number of problems account for most of the distrust, and they are usually data problems rather than configuration problems.
This is also the honest first engagement. It is bounded, it produces something useful whether or not you continue, and it means the implementation quote that follows is based on what is actually there.
Who owns it after go-live
The question that determines whether any of the above still works in a year.
HubSpot is not a system you install. It changes as the business changes: new products, new segments, new reporting demands, new team members with new requests. Without a named owner, entropy is quick and specific. Properties multiply because it is easier to create a new one than find the existing one. Workflows conflict. Reports drift from the definitions they were built on. Within about a year you are back to not trusting the numbers.
Companies solve this three ways. A full-time HubSpot admin, correct once the portal is complex enough to justify the salary. An existing person part-time, which works when they have genuine capacity and fails when it is a fourth priority. Or an outsourced administrator, which is what we provide: a named person with reserved hours who handles requests, keeps the data clean, builds new automation, and keeps the whole thing coherent.
We would rather build portals we also run, because knowing you will maintain something changes how you build it.
How to choose a HubSpot partner
Useful whether or not you talk to us, and the criteria are not the obvious ones.
Tier is a poor signal. Partner tiers weight sold licence volume heavily. A high tier tells you the agency sells a lot of HubSpot, not that they are good at implementing it. Ask instead what they have built that the interface does not do natively.
Ask who does the work. Some partners are consultancies that subcontract the build. Not automatically bad, worth knowing, and it explains a lot of communication problems later.
Ask about data. If the answer to “how do you handle deduplication and property architecture” is thin, you are buying a configuration exercise rather than an implementation.
Ask what happens after handover, and whether they will still be there. An agency with no ongoing offer has no incentive to build something maintainable.
Ask whether they resell licences. We do not. A partner earning margin on your subscription has a reason to put you on a larger tier, and you should at least know whether that incentive is present.
Axiolo is a HubSpot Solutions Partner. What actually distinguishes us is narrower than the badge: the same team that specifies the work also writes the code, so custom objects, API integrations, and serverless functions are in scope rather than referred out. Most of what we are called in to fix is marketing engineering that stalled because the people who diagnosed it could not implement it.
Where we are not the right fit
We do not resell HubSpot licences, so if you want a partner who bundles the subscription, that is not us.
We are not a HubSpot CMS web shop. We build sites in Astro, Next.js, and React and connect them to HubSpot. If you specifically want the site built on HubSpot CMS, partners specialise in that.
We do not do Service Hub-only implementations for large support organisations, which is a distinct discipline with its own specialists.
And if your portal is basically fine and you need occasional help, a retainer is the wrong shape. Ask for the audit and take the list to whoever you already have.