HubSpot implementation that your team actually adopts
Buying HubSpot is easy. Getting your team to use it, with data you trust and reports that survive a leadership question, is the actual project.
What is HubSpot implementation?
HubSpot Implementation is the configuration, data migration and process work required to make HubSpot the working system of record for marketing, sales and service. It covers property design, lifecycle stages, pipelines, automation, custom objects, reporting and user training. It suits Australian businesses adopting HubSpot or rescuing a rollout that stalled.
Get a fixed written quote- Typical timeline
- 4 to 10 weeks
- What drives cost
- The state of your existing data, how many hubs are in scope, whether custom objects are needed, and how many systems have to integrate.
- Best for
- Businesses adopting HubSpot properly, or repairing a rushed rollout
- You own
- The HubSpot portal, every record in it and all exported configuration
- Built with
- Property architecture, lifecycle stages, pipelines, workflows, custom objects, dashboards
Your handover
What an implementation covers beyond turning it on
A HubSpot portal arrives with a default configuration built for a generic business, which is to say for nobody. An implementation replaces those defaults with decisions that match how you actually sell and serve. Property architecture, so the fields that exist are the fields you use and the ones you do not are removed before anybody fills them in wrongly. Lifecycle stages with written definitions, because subscriber, lead, marketing qualified and sales qualified mean nothing until your team agrees what moves a contact between them.
- 01Written lifecycle and deal stage definitions
- 02Property architecture with unused defaults removed
- 03Pipelines, teams and permission structure configured
- 04Deduplicated and normalised data migration with reconciliation
- 05Consent and subscription history migrated intact
- 06Routing, notification and follow up workflows
- Custom objects where justified, documented with the rationale
- Leadership dashboards tied to agreed questions
- Role-based training recordings and an administrator runbook
Forms, tracking and lead capture wired to the right properties
Then pipelines and deal stages that mirror your real sales process rather than a software vendor's idea of one, with entry criteria per stage. Forms, tracking and lead capture wired to the right properties. Workflows for routing, notification and follow up. Permissions and teams so people see what they should. Templates and sequences for the emails your sales team sends repeatedly. Integration with the systems HubSpot has to coexist with, most often accounting, a website and sometimes an ERP.
Finally, adoption. A perfect configuration that nobody uses has produced nothing. We train by role rather than by feature, so a salesperson learns the four things they will do daily instead of a tour of a product they will never fully explore.
Consent history migrates too, and this is not optional for Australian senders.
Migrating data without importing the mess
Migration is where implementations quietly fail. The temptation is to export everything from the old system and import it, which reproduces years of duplicates, inconsistent values and dead records in a clean new portal within an afternoon. Now the shiny system has the same trust problem the old one had, and it acquired it on day one.
Records are profiled first to see what is genuinely there
We treat migration as an editorial exercise. Records are profiled first to see what is genuinely there. Duplicates are identified and merged with documented rules. Free text fields that should be controlled values get mapped to picklists. Phone numbers and states are normalised. Contacts with no activity for years are imported into a suppressed status or left behind entirely, depending on your retention obligations. Associations between contacts, companies and deals are rebuilt properly, because a contact without a company association is invisible to half the reporting you will want.
Consent history migrates too, and this is not optional for Australian senders. HubSpot's subscription types and legal basis fields need populating from your old system so that a person who opted out three years ago does not receive a welcome email because their consent state was left behind. The Spam Act 2003 obligations we cover in email automation apply from your first send in the new portal, not from a grace period.
Every migration runs into a sandbox or a staging import first, with record counts reconciled against the source before anything touches production.
How the engagement runs
How a HubSpot implementation runs
We sequence definitions before configuration and configuration before migration, because importing data into an architecture you have not agreed means importing it twice. The definitions stage looks slow and is the part that saves the most time overall.
- 01DiscoveryCurrent systems, sales and service processes, reporting requirements and what is actually broken today
- 02DefinitionsLifecycle stages, deal stages, required properties and ownership rules agreed and written down
- 03ArchitectureProperty design, pipelines, teams, permissions and any custom objects justified in writing
- 04Data preparationProfiling, deduplication, normalisation and consent mapping before any import
- 05MigrationStaged import with reconciliation of record counts and associations against the source
- 06Automation and integrationRouting, notifications, sequences, forms, website tracking and system connections
- 07Training and go liveRole-based sessions, an adoption review at 30 days, and dashboards signed off with leadership
Two decisions on your side that keep the project moving
We also stage the rollout by hub rather than switching everything on at once. Sales adopting a CRM while marketing rebuilds its email program and service redesigns ticketing is three change programs competing for the same people's attention.
Custom objects: when you need them and when you do not
HubSpot models contacts, companies, deals and tickets natively, and for a large share of businesses those four are sufficient. Custom objects, available on higher tiers, let you add entities the standard model does not have. The question is whether your business genuinely has a fifth thing.
A vehicle for an automotive dealer, with a service history and an owner who changes
Sometimes it clearly does. A vehicle for an automotive dealer, with a service history and an owner who changes. A property for a real estate agency, associated with vendors, buyers and multiple deals over time. A course intake for a training organisation. A subscription or contract with its own renewal date, value and status. In each case the entity has its own lifecycle, its own reporting needs and relationships to more than one contact, which is exactly what a custom object is for.
Often it does not. We are frequently asked for a custom object when a well designed set of properties on an existing object would do the job, and the custom object would add complexity, licensing cost and reporting friction for no benefit. The test we apply is whether the thing has a life independent of the deal or contact it attaches to. If it does not, it is a property. If it does, and you find yourself keeping a spreadsheet beside HubSpot to track it, that spreadsheet is the evidence. Businesses in property and automotive hit this pattern more than most.
Reporting leadership will actually use
Most HubSpot dashboards we inherit were built by whoever set the portal up and answer questions nobody asks. The useful approach is backwards: start with the four or five questions your leadership team asks every month, then build only the reports that answer them and delete the rest.
How long does a deal take by stage and where does it stall
Those questions are usually consistent. Where is pipeline coming from and is it enough. How long does a deal take by stage and where does it stall. What is the conversion rate from enquiry through to closed business by source. Which customers are at risk. Answering them properly requires the plumbing described earlier, since a source report is only as good as your campaign tagging and a stage duration report is meaningless if deals are moved in bulk on the last day of the month.
Where the reporting needs to combine HubSpot data with finance, delivery or operational systems, we usually surface it outside HubSpot in Power BI or Looker Studio rather than fighting the native reporting to do something it was not designed for. Marketing sourced pipeline should reconcile with the lifecycle work in marketing automation, and if the two disagree, that is the first thing worth fixing.
When HubSpot is the wrong platform
If your organisation is deeply committed to Microsoft, with Entra ID, Teams and a Dynamics investment already in place, adding HubSpot means running two ecosystems and integrating them forever. Sometimes that is still the right call because the marketing tooling is better suited, but it should be a deliberate decision rather than a default, and it is worth comparing against what you can build with the Microsoft stack you already licence.
HubSpot enforces nothing you have not defined
If your commercial model is unusual, HubSpot will resist. Complex quoting with configurable products, project delivery with milestone billing, layered account hierarchies with contracted pricing, or heavy inventory dependence all sit outside what the deal object handles gracefully. You can extend a long way with custom objects and integration, but there is a point where you are building an application inside a CRM. Past that point a purpose built CRM or an integration with your ERP is cheaper and more stable.
And if the real problem is that nobody follows a sales process, changing platform will not create one. HubSpot enforces nothing you have not defined. We have told prospective clients that their existing CRM is fine and that the money would be better spent defining the process and cleaning the data, which is the CRM automation conversation rather than a migration. It is a shorter project and it usually produces the improvement they were hoping the new platform would deliver.
How we scope it
Four ways to scope your HubSpot Implementation project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
First workflows
The two or three processes costing the most time now
Fixed written quote, agreed before work starts
- Written lifecycle and deal stage definitions
- Property architecture with unused defaults removed
- Pipelines, teams and permission structure configured
Connected stack
The systems you already pay for, talking to each other
Fixed written quote, agreed before work starts
- Everything in First workflows
- Deduplicated and normalised data migration with reconciliation
- Consent and subscription history migrated intact
- Routing, notification and follow up workflows
Operations platform
Operations running on automation you can see and audit
Fixed written quote, agreed before work starts
- Everything in Connected stack
- Custom objects where justified, documented with the rationale
- Leadership dashboards tied to agreed questions
- Role-based training recordings and an administrator runbook
Automation care
Watching, fixing and extending as the processes change
Rolling monthly, quoted in writing
- Every workflow monitored, with alerts that reach a person
- Fixes when an upstream system changes its behaviour
- New workflows added from your backlog each month
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Working with us
Can you migrate us from Salesforce, Pipedrive or a spreadsheet?
Yes, and the source matters less than the state of the data. Spreadsheets are often easier than a mature CRM because there is less accumulated structure to unpick. From Salesforce the care goes into object mapping, associations and history. In every case we profile and clean before importing, run the migration into a staging import first, and reconcile counts before going live.
What happens if our team does not use it?
That is the risk we design against, which is why definitions and role-based training matter more than feature configuration. At the 30 day review we look at usage data rather than opinions: who is logging activities, which stages are being skipped, where records are being created outside the process. Then we simplify. Low adoption is almost always a sign the system asks for more than it gives back.
Do you provide ongoing HubSpot support?
Yes, usually as a light monthly retainer covering configuration changes, new workflows, reporting updates and administrator questions. Portals drift as the business changes, and an unmaintained HubSpot instance accumulates unused properties and stale workflows the same way any system does. You can also run it internally using the administrator runbook, and plenty of clients do.
Detail and edge cases
How long does a HubSpot implementation take?
Typically 4 to 10 weeks. Definitions and architecture take the first two weeks, data preparation and migration the middle stretch, and automation, reporting and training the remainder. Multi hub rollouts covering marketing, sales and service take longer and we usually stage them, because asking every team to change how they work in the same fortnight tends to produce resistance rather than adoption.
What drives the cost of an implementation?
The state of your existing data, how many hubs are in scope, whether custom objects are needed, and how many systems have to integrate. Messy data from a long running legacy CRM is the most common reason a project is larger than expected. We scope on a discovery call and provide a fixed written quote. Your HubSpot subscription is a direct arrangement between you and HubSpot.
Do we own the portal and the data?
Yes. The HubSpot portal is registered to your business with your billing details, all records are exportable, and configuration documentation is handed to you. We work as users in your portal at an access level you control and can revoke. Nothing about the implementation depends on us continuing to be involved.
Related services
Get your HubSpot rollout scoped properly
Tell us which hubs you have, what system you are coming from and what leadership needs to see. We reply within one business day with a plan and a fixed written quote.