HubSpot Implementation: What Is the Right Order of Phases?

Implementing HubSpot rarely fails for lack of competence. It fails on order.

The portal arrives empty, the task list looks parallel, and the team starts with what is most visible: building the first landing page, setting up the first email workflow.

Three weeks later, that same team discovers that emails go out with a sender nobody recognizes, that the traffic report is empty, and that the landing page sits on a subdomain that will have to change.

None of that is a bug. It is an unmapped dependency.

In implementation projects, the difference between a timeline that holds and one that stretches almost always lies in the first week, in deciding which step comes before which.

This guide organizes the configurations into the six phases in which they actually chain together, with what each one requires and what it unlocks for the next.

What is HubSpot implementation and what does it include?

Implementing HubSpot is the configuration work that connects the platform to the company's real operation.

It involves creating the test environment, defining users and permissions, installing tracking on the site, connecting ad and social accounts, configuring domains and email authentication, switching on privacy rules, and migrating existing content.

Caption: Each implementation phase unlocks the next: what comes first defines what can be configured afterward.

It is not the same thing as learning to use the tool.

That distinction saves weeks. Training teaches the team to build a workflow; implementation guarantees that the workflow, when it fires, reaches the right recipient, from the right sender, and logs the result in the report. One is knowledge, the other is infrastructure.

Anyone who wants the overview before the detail will find in the essential implementation steps the more strategic read of the same territory.

It is also worth separating what does not belong to the technical configuration scope: defining personas, designing the journey, content architecture, and acquisition strategy. Those are decisions that precede or accompany implementation, but follow their own logic.

Anyone who already understands what HubSpot CRM delivers as a platform tends to arrive better prepared for those choices.

The configuration inventory of a standard project covers thirteen fronts:

• Test environment (sandbox), when the subscription allows it.
• Users, seats, and permissions.
• Contact record customization.
• Tracking code on the site.
• Ad accounts.
• Social media accounts.
• Brands in the portal, when the operation has more than one.
• Content domains and subdomains.
• Sending domain and email authentication.
• Conversations inbox.
• WhatsApp Business channel.
• Privacy, consent, and data protection.
• Support structure and ticket pipeline.

Add content migration to that, when the client is leaving another platform, and you have the full scope. Fourteen fronts, with cross-dependencies among most of them.

In what order should HubSpot configurations be done?

The order follows technical dependencies, not perceived urgency. Environment and access come first, because everything afterward happens inside them. The inbox precedes the messaging channels. Domain precedes email, always. Privacy closes what the channels opened.

Migration requires a ready domain, and structured support comes after go-live.

The most common mistake is starting with phase 5.

It makes sense from the standpoint of desire: migrating the site is the most visible change, the one the director notices. But migrating before connecting the domain means republishing everything afterward, and migrating before installing tracking means losing the baseline for comparing before and after.

The dependencies that matter most are eight:

The remaining steps can run in parallel, which opens room to gain time on the timeline.

That is the difference between a sequential ten-week timeline and a six-week one with parallelism. Ads, social media, and users depend on nothing beyond account access, so they can move forward while IT resolves DNS.

Phase 1: how do you prepare environment, users, and tracking?

Phase 1 establishes where the work happens and who can do it. There are four configurations: creating the test environment when available, adding users with the correct permissions, installing the tracking code on the site, and defining what the contact record shows.

None of them depends on any area beyond technology.

The test environment comes before any change

HubSpot's sandbox is a copy of the production account's functionality, created to test automations and integrations without affecting the account that is live.

The detail usually catches teams by surprise: the feature is exclusive to Enterprise subscriptions, with one standard sandbox per account.

Anyone on Professional does not have that environment.

The alternative in that case is process discipline: test lists with internal contacts, workflows started in manual mode, and paired review before any publication. It works, but it requires an explicit agreement, not improvisation.

It is also worth knowing what the sandbox does not copy: active integrations have to be reconnected manually, and record identifiers differ between the two environments. Testing an integration in the sandbox does not guarantee it will behave the same in production.

Users: the decision that moves the cost

Adding users looks like paperwork, but this is where you define how much the account will cost per month. HubSpot works with different seat types, and two of them are free.

The View-Only Seat is free and unlimited. It allows viewing records, dashboards, and reports, without editing. It solves the classic case of the director who only wants to follow the numbers.

The Partner Seat is also free, intended for employees of eligible HubSpot partners. In practice, that means the agency doing the implementation does not have to consume a paid seat from the client.

Two free configurations that many people discover after having bought an unnecessary seat.

On permissions, the guidance in HubSpot's own documentation is to assign the least privilege necessary for the role. Removing edit permission, for example, prevents someone from deleting activities logged on a contact, which is irreversible.

Tracking: installing is easy, validating is what matters

The tracking code is unique per account and lets HubSpot monitor site traffic, recognize form submissions, and enable features such as live chat.

On pages hosted by HubSpot itself, it is already included; manual installation is only necessary on external sites, before the closing body tag.

Pasting the code takes two minutes. Confirming that it is working is what prevents rework.

HubSpot documents five ways to verify the installation, and the most conclusive one is not looking at the source code, it is opening the browser's network tab and looking for the __ptq.gif request with status 200.

That request confirms the tracking is actually firing, not merely present on the page.

The contact record: what the team sees in the first seconds

Granting access solves half the problem. The other half is what appears on screen when someone opens a contact record to take a call.

HubSpot's default record shows the properties the platform considers universal, not the ones the operation uses. Whoever handles the applicant needs to see program of interest, source, and stage before scrolling.

When the decisive information sits three clicks below, the team does the predictable thing: it checks the old spreadsheet and logs it in the CRM later, if it remembers.

That is why customizing the contact and deal records belongs in phase 1, alongside adding users. It is a cheap configuration at the start and an expensive one to recover after the team has built the habit of working outside the system.

Phase 2: how do you connect ads, social media, and WhatsApp?

Phase 2 connects the acquisition and conversation channels to the platform. It opens with the conversations inbox, which is where messaging channels start arriving, and continues through ads, social media, and WhatsApp.

Almost everything here depends on admin permission in the source accounts.

The bottleneck is rarely technical: it is getting the right access from the right person inside the company.

Inbox: the container that comes before the messaging channels

The conversations inbox is the single place where team email, chat, forms, Facebook Messenger, WhatsApp, and calls arrive. It exists across all products and plans, including the free tools.

Order matters because a messaging channel does not connect into a void: it is connected inside an inbox that already exists, with access and assignment rules defined.

Two decisions precede any connection. Which shared addresses the operation has, and who sees what arrives in each of them.

Connecting a channel before agreeing on who answers what is the most expensive mistake in this step: the inbox receives everything, nobody owns the queue, and support ends up worse than it was before centralization.

The per-channel requirements, the assignment rules, and the difference between team email and personal email are defined in HubSpot's conversations inbox.

Ads: four networks, not three

HubSpot connects Facebook, LinkedIn, Google, and TikTok accounts. The inclusion of TikTok Ads goes unnoticed in much of the available material, and that matters for operations investing in the channel.

The connection enables syncing leads from lead ad forms straight into the CRM, installing pixels, and reading performance metrics inside the platform.

Two numbers prevent false alarms. Contact and company audiences can take 24 to 48 hours to sync, and LinkedIn audience reports can take up to 72.

Each network also requires a minimum audience size to activate: LinkedIn asks for at least 300 members, and Google's search network asks for 1,000 active users in the last 30 days.

An audience that “did not show up” is almost always just below the minimum or inside the sync window.

Social media: the problem is requirements, not the step-by-step

Six channels connect to HubSpot's social tool: Facebook, Instagram, LinkedIn, TikTok, X, and YouTube. What blocks the connection are each one's requirements.

Instagram requires a business account linked to a Facebook page the user administers, which excludes personal and creator accounts. Facebook does not connect personal profiles, only pages with admin access. LinkedIn accepts profiles and company pages, but not groups.

And there is a maintenance detail that causes trouble months after the project ends: connected Facebook pages stay authorized for 90 days before requiring re-authentication. Anyone who does not know that finds out when a scheduled post simply does not publish.

WhatsApp: the most delicate decision of the phase

Connecting WhatsApp Business to HubSpot requires an inbox already configured, because that is where the channel gets connected. Add to that Marketing Hub or Service Hub on Professional or Enterprise plans, a WhatsApp Business account, and admin permission in Meta Business Manager.

Three consequences change the decision and deserve to be discussed before, not after.

Messages stop appearing in the WhatsApp app, because the number is now operated by the platform. No prior history is synced, only new conversations. And the session stays open for 24 hours after the contact's last reply; outside that window, you can only send a previously approved template message.

For operations that cannot lose the use of the app, there is coexistence mode, which HubSpot's documentation treats as an alternative connection path.

Phase 3: how do you configure domains, DNS, and email authentication?

Phase 3 defines where the content will live and guarantees that email goes out with the company's sender address.

It involves deciding the split by brand, connecting content domains and subdomains, applying the corresponding DNS records, and configuring the sending domain with DKIM, SPF, and DMARC. It is the phase that depends most on the DNS provider.

Brands in the portal: the decision that comes before the subdomain

Anyone operating more than one brand decides the split before choosing the subdomain.

The Brands feature, which HubSpot used to call Business Units, allows keeping domain, tracking code, forms, and email subscription types separate by brand inside a single portal.

It is a paid add-on, not a feature included in the plan, and each instance unlocks one brand.

The practical consequence lands straight on the DNS timeline. Each separate brand comes with its own domain to connect, so the decision changes how many domains the subscription needs to cover and how many requests go to the technology team.

A group with several schools, or an institution with an on-campus brand and an online brand, has to settle that account before sending the first record to the provider.

What can be separated by brand, what stays shared in the portal, and when a separate portal comes out cheaper all depend on how the Business Units are organized in the portal.

Content domains: A record or CNAME

HubSpot hosts website pages, landing pages, blog posts, knowledge base articles, and web versions of emails on your own domain. Root domains require updating A records; subdomains require CNAME.

The platform delivers the values ready to use, in a table with host and required data.

The error that stalls this step most is not in HubSpot, it is at the DNS provider. Several providers automatically append the domain to the pasted value, producing duplicate entries such as landing.yourcompany.com.yourcompany.com.

The fix is manual and HubSpot's documentation flags the behavior.

Once connected, the SSL certificate is provisioned automatically. It usually takes minutes, but can reach four hours, which is worth noting in the timeline so it does not trigger a false alarm the day before a launch.

Sending domain: why the sender changes without it

Here is the point that resolves most deliverability problems on a new project. Without a connected sending domain, HubSpot automatically changes the sender address to use a domain it manages.

In other words, the campaign goes out, but from a sender the recipient does not recognize.

The sending domain has to be a subdomain distinct from the one hosting pages and posts, and that separation exists to protect the root domain's reputation. There are four record types to apply: DKIM with two CNAMEs, SPF with one TXT, DMARC with one TXT, and one MX record.

Propagation normally takes 10 to 70 minutes, occasionally up to 48 hours.

It is worth sizing the risk with an external data point. Since February 2024, Google requires anyone sending more than 5,000 messages per day to Gmail accounts to have SPF, DKIM, and DMARC configured on the sending domain, and to keep the spam rate below 0.10%. An average enrollment campaign clears that volume easily.

Email authentication has stopped being a technical refinement. It is a condition of delivery.

Phase 4: how do you bring the account into privacy compliance?

Phase 4 switches on the portal's privacy settings and organizes consent across every connected channel.

It involves turning on the privacy rules, publishing the cookie banner, defining the legal basis, adding consent fields to forms, structuring email subscription types, and guaranteeing unsubscribes.

It comes after the channels on purpose, because consent is configured per channel.

The starting point is the law, not the tool. Brazil's Law 13,709 defines consent as a free, informed, and unambiguous statement for a determined purpose, declares blanket authorizations void, and guarantees revocation through a free and straightforward procedure.

Translated into configuration: no single checkbox covering everything, and unsubscribing has to be simple.

HubSpot frames the LGPD as requiring a legal basis in two layers: one to process the data, another to communicate with the person. They are separate decisions, and treating them as one is a common source of inconsistency.

Two traps deserve special attention because they create silent liability.

The first: switching on the privacy settings adds consent sections only to new forms. Forms that already exist have to be updated manually, one by one. Anyone trusting the automatic route ends up with half their lead capture out of compliance.

The second: activation disables email open and click tracking for contacts without a documented legal basis. The report changes overnight, and the team reads it as a drop in performance when it is a change in measurement method.

A note of precision that applies to any content on the subject: the LGPD does not name double opt-in or unsubscribe links specifically. It requires consent for a determined purpose and straightforward revocation.

Double opt-in and unsubscribe links are means of evidencing and operationalizing that, including for the purpose of proof.

Phase 5: how do you migrate content and go live?

Phase 5 brings existing content onto the platform and flips the switch. It involves migrating website pages, importing the blog archive, mapping redirects from the old URLs, and running the publishing checklist before pointing the DNS.

It is the phase with the highest risk of losing organic traffic and the one that benefits most from planning.

HubSpot's official website migration service works with a limit of 150 pages and a two- to four-week timeline after receiving the materials, with a 60-day window to report design issues.

What falls outside the scope matters more than what falls inside.

The documentation explicitly excludes gated content, e-commerce, advanced forms such as multi-step forms and calculators, database-driven content, and third-party integrations.

For an educational institution, that describes a good part of the student portal.

On preserving rankings, HubSpot's redirect tool supports standard and flexible pattern redirects, with the 301 code as the default for new redirects, and accepts bulk uploads by spreadsheet.

There is a decisive limitation: redirects only work on domains connected to and hosted by HubSpot. Domains that remain hosted elsewhere have to be handled at the origin provider.

For the blog, there are four official import paths. The most automated is the direct WordPress connection, which depends on the REST API being accessible and is often blocked by a security plugin.

It brings the title, SEO title, author, date, featured image, categories, tags, meta description, and post body. It does not bring custom post types.

The go-live checklist in the documentation includes reviewing migrated forms, configuring the blog, uploading the favicon, integrating analytics, excluding internal traffic from metrics, reviewing SEO recommendations, bulk-loading the redirects, and only then connecting the domain and updating the DNS.

In that order. DNS is the last step, not the first.

Phase 6: how do you structure support after go-live?

Phase 6 organizes what happens once the operation is live: the ticket that comes in, the path it travels, and the feedback it generates. It involves entry channels, ticket pipeline, routing and SLA rules, customer portal, and satisfaction surveys.

It comes last because it depends on nearly everything before it: channel connected in phase 2, domain connected in phase 3, and consent resolved in phase 4.

A ticket comes in through four paths: manual creation, connected channel, workflow, and API. Only the connected channel creates a ticket on its own, and the form is the only one that arrives classified, because the questions are yours.

One platform change catches teams off guard. Accounts created after April 2024 no longer create tickets from channels linked to the conversations inbox, and ticket management goes through the help desk.

The pipeline organizes progress. The most common mistake is mirroring the org chart, creating one queue per department, where the ticket that belongs to two areas ends up homeless.

The criterion that holds up is the type of resolution, not the owner. A ticket resolved in one reply follows one flow; a ticket that depends on a student document follows another.

Routing decides who answers, and it stalls more on seats than on configuration: automatic distribution of incoming messages requires a paid seat assigned to whoever will receive them.

The customer portal is the piece that most reduces follow-up calls and the one fewest people configure. It is a logged-in area where the requester checks their own tickets without opening email.

It requires Service Hub Professional or Enterprise and a connected domain, because HubSpot-provided domains do not send the access emails. It is the only piece of phase 6 that goes back to depending on phase 3.

The survey closes the loop, and there are three types with different objectives: loyalty, which measures NPS; support, which measures effort at ticket closing; and satisfaction, which measures CSAT.

Firing all three at once overloads the database and drives down the response rate of all of them.

The complete design, with what each piece requires in subscription terms and the portal's access traps, depends on the support structure you will design in Service.

How long does it take to implement HubSpot from scratch?

There is no single number, because the timeline depends on how many channels come in, whether there is content migration, and how quickly the client's technology team moves. What does exist are official references to calibrate expectations, and they help build a timeline without guessing.

HubSpot's assisted onboarding programs for Enterprise plans work with a 120-day window, with one to two weekly meetings in the advanced format and two to three in the premier format.

Within that period, some timelines are fixed and verifiable:

Tabela: Timelines stated in HubSpot's official documentation; the sum is not the project timeline, because several steps run in parallel.

In practice, what stretches a timeline is not those durations. It is waiting for access: admin permission on the ad account, the DNS provider credential, the decision about which WhatsApp number to commit.

Making those three requests in week one is worth more than any execution optimization.

On the return once configured, HubSpot publishes aggregate data from its base of more than 268,000 customers across 135 countries, pointing to increases in leads and closed deals within the first six months.

HubSpot itself notes that results vary by industry, geography, and business stage, which is reasonable to consider before turning a global average into an internal target.

Who does each step: your team, your IT, or the partner?

The split that works separates by type of access, not by seniority. Marketing handles what lives inside the portal. Technology handles what requires infrastructure credentials. The partner takes on what depends on project repertoire, meaning the decisions that only become obvious after having done them several times.

Here is how that organizes:

The right-hand column is the one that usually stalls: nearly every step depends on something another area has to release.

What changes when there is a partner on the project is less the execution and more the order. Much of the value lies in knowing that domain precedes email, that switching on privacy does not touch old forms, and that the chosen WhatsApp number is not easy to walk back.

Domain, privacy, and the WhatsApp number are sequence decisions, and getting them wrong costs rework, not configuration.

For anyone evaluating that support, it is worth understanding the criteria for choosing the right partner before closing the scope, and knowing the onboarding best practices that sustain adoption once configuration is finished.

Which mistakes delay a HubSpot implementation?

Delays concentrate in a few patterns, and almost all of them are about sequence or expectation. None of them is a platform problem; they are decisions made without the information that would surface one phase later.

Recognizing them early shortens the timeline more than speeding up execution.

• Starting with migration. It is the most visible step and the one that depends most on the others. Without a connected domain, there are no redirects; without tracking installed, there is no baseline for comparing before and after.
• Discovering a subscription requirement mid-task. Sandbox requires Enterprise. The social tool asks for a specific plan. WhatsApp requires Professional or above. Checking that in week one avoids replanning in week four, and choosing the plan gets easier when the requirements list comes before the subscription.
• Treating email as content when the problem is DNS. The team rewrites the subject line, tests send times, changes segmentation, and the cause was the sender replaced for lack of an authenticated sending domain.
• Buying seats without looking at the free ones. Before paying for access for someone who only checks reports, it is worth verifying whether the View-Only Seat solves it.
• Switching on privacy and calling it done. The old forms still have no consent field, and the email report changes behavior without warning.
• Not documenting the subdomain decision. Changing it later means redoing publication and redirects. Decide once, in writing, with whoever has DNS access in the conversation.

An implementation checklist shared with the team resolves much of this, because it turns implicit dependency into a visible task with an owner.

Frequently asked questions about HubSpot implementation

So, how do you make a HubSpot implementation work?

The short answer is sequence. The platform is well documented, the configurations are accessible, and no individual step is difficult.

What separates a project that lands on time from one that drags is knowing what depends on what before starting, and requesting the right access in the first week instead of the third.

If you are building that timeline now, start with three decisions that unlock all the others: which subdomain hosts each type of content, which address will be the sender for campaigns, and who, in your company, has access to the DNS provider.

Without those three, half the phases sit on hold.

And if at some point the configuration runs into a subscription limit, a platform requirement nobody had mapped, or an old contact database with no recorded consent, those are exactly the points where a conversation resolves things faster than a sequence of attempts.

The mkt4edu team works on HubSpot implementation for enrollment operations, and you can talk to us to review your scenario before committing to the timeline.