vTiger CRM to HubSpot Migration

Every automation running across vTiger's modules, the standard ones and whatever custom logic has accumulated on top, falls into this one line.

HubSpot: Workflows

Rebuild happens rule by rule, and only once the pipelines and properties underneath already exist. Start with an inventory rather than a rebuild: an instance that has run for years usually carries several automations nobody remembers the purpose of, and those are worth dropping rather than reproducing.

Whatever fires an email automatically off the back of something happening on a record falls under this.

HubSpot: Workflows and sequences

Classify each one individually as a marketing send or a sales sequence rather than as a single group, because the consent rules HubSpot applies differ between the two, and getting that classification wrong is a compliance question, not a cosmetic one.

Anything set to fire the moment a particular field changes value sits in this category.

HubSpot: Property-based workflow enrolment

None of it can be rebuilt until the field exists as a genuine HubSpot property carrying the same values it did in vTiger, so this step has to wait for the custom field mapping to be finished first, not run alongside it.

The rules deciding who gets told when a given event happens belong here.

HubSpot: Notification settings and workflow internal emails

HubSpot spreads this across two separate settings areas rather than one, so check both of them deliberately: rebuilding only the half that is obvious leaves the other half of the old alerting silently missing.

Whatever used to decide which salesperson a new form submission landed with needs rebuilding here.

HubSpot: Workflow rotation actions

Get the users and teams set up correctly before touching the routing itself, then prove it works with real submissions rather than trusting the configuration on its own.

Anywhere a record used to need sign-off before it could move forward sits in this category.

HubSpot: Workflow approval actions, or an external tool

HubSpot's own approval capability covers less ground than a mature vTiger instance typically expects. Work out exactly which steps genuinely need sign-off before assuming the old process can simply be rebuilt as it stood; a narrower feature set is not always a problem once the real requirement is named plainly.

Any saved dashboard blending sales and support metrics together sits in this category.

HubSpot: Dashboards

Build these only once the underlying reports already exist in HubSpot, not in parallel with them, since a dashboard built against a report that later changes shape has to be rebuilt twice.

Any report that sums or averages figures across grouped records belongs here.

HubSpot: Custom reports

HubSpot can do this kind of aggregation, but the way it arranges the calculation is genuinely different from vTiger's. Rebuild starting from the question the original report was actually answering rather than trying to reproduce its exact shape, and the result usually works better than a literal copy would.

Sales reporting that runs over the pipeline itself sits in this line.

HubSpot: Deal reports

None of this works until the deal import is clean and every deal owner resolves to an actual HubSpot user rather than a name that no longer maps to anyone.

Reporting on what each individual user has actually been doing falls here.

HubSpot: Activity reports

This reporting effectively restarts at the point of migration unless the activity history was extracted separately, and that extraction is the expensive item already flagged above, not a small add-on to this one.

Whatever report used to arrive by email on a fixed schedule sits in this category.

HubSpot: Scheduled dashboard emails

HubSpot schedules whole dashboards rather than a single report on its own, so the old grouping of who received which report may need rearranging to fit that model rather than transferring across unchanged.

Whichever chart types vTiger reporting relied on need matching in HubSpot.

HubSpot: Report visualisations

Most of vTiger's chart types have a direct HubSpot counterpart. Where one genuinely does not, the question the chart was actually answering usually still survives being shown a different way, so the loss is rarely as real as it first looks.

The sales stages themselves, and the win probability sitting behind each one, need setting up fresh.

HubSpot: Deal pipelines, stages and stage probability

Build this before almost anything else, probabilities included, because forecasting has nothing to work from until it exists.

Every custom field across Contacts, Organisations, Opportunities and the rest of the modules needs its own place in HubSpot.

HubSpot: Custom properties

vTiger runs more module types than HubSpot has standard objects, so every field has to be individually sorted into wherever it actually ends up living, and the field's type needs mapping just as carefully as its name does, not assumed to carry over automatically because the label matches.

Templates used both for outbound sends and for merging into documents fall under this line.

HubSpot: Email templates and snippets

Email templates themselves rebuild without much difficulty. Mail merge into a standalone document is a different problem: HubSpot has no direct equivalent for it, and closing that gap likely means bringing in a marketplace tool rather than expecting a native feature to cover it.

Every form currently feeding leads into vTiger needs rebuilding on the HubSpot side.

HubSpot: Forms

Swap every embed code across at the moment of cutover, not gradually, or leads simply keep arriving in the old system while the team is already working out of the new one.

Whatever logic vTiger used to rank and qualify leads has to be rebuilt on the other side.

HubSpot: Score properties

There is no import path for this: it has to be built from scratch, against whichever signals HubSpot actually records rather than the ones vTiger happened to track.

The layout of fields on a record, arranged differently for each profile, needs deciding fresh.

HubSpot: Record customisation

HubSpot's control over record layout is less granular than vTiger offered, so this is not a place a full like-for-like rebuild is even possible. Agree with the team what actually needs to be visible on screen day to day, rather than trying to reproduce every layout vTiger happened to have.

The way campaigns get defined, and how their results are actually tracked afterwards, both need settling again.

HubSpot: Campaigns and tracking URLs

Settle the tracking convention before the very first HubSpot send goes out; change it partway through and the analytics history ends up cut into two incompatible halves that never quite line up again.

Every login, and the role attached to it, has to be created fresh in HubSpot.

HubSpot: Users and permission sets

Set these up before a single record is imported, since record ownership has nothing to resolve to until the users themselves already exist.

Control over which profile can see which module and which field needs rebuilding individually.

HubSpot: Permission sets

vTiger's profiles go finer-grained at the individual field level than HubSpot's model does. Where a field genuinely needs that level of protection, confirm HubSpot can actually enforce it before anyone is told it will, rather than assuming the granularity carried across.

The rules deciding who is allowed to see which records need rebuilding under HubSpot's own model.

HubSpot: Record access settings

HubSpot partitions record visibility on a different logic entirely, so a straight copy of the old rules rarely maps cleanly. Work out what genuinely needs hiding from whom before reproducing rules that may have grown broader than they needed to be over the years.

vTiger's territory hierarchy, and however it drove assignment, needs an equivalent built from nothing.

HubSpot: Properties plus workflow-based assignment

HubSpot has no dedicated territory object at all, so this has to be modelled instead: design the property that will carry the territory value first, then build the assignment rules on top of it, in that order.

The grouping used for assignment and sharing across users needs a HubSpot equivalent.

HubSpot: Teams

Map what each grouping was actually meant to achieve rather than copying its structure directly: a literal, field-for-field copy tends to lock access down more tightly than was ever intended.

Whatever IMAP and SMTP connections vTiger has been sending and receiving through need reconnecting on the other side.

HubSpot: Connected inbox and a connected sending domain

A single vTiger setting splits into two separate jobs in HubSpot: connecting each user's mailbox individually, and authenticating the sending domain at the account level. Start the DNS side of that early, since domain authentication has its own lead time regardless of how quickly the rest of the setup goes.

Whatever sits behind calling, an Asterisk box, a Twilio-driven PBX or similar, needs its own answer on the other side.

HubSpot: HubSpot calling or a marketplace provider

A self-hosted PBX integration rarely has a matching HubSpot counterpart waiting for it, so confirm what the replacement actually is before the contract is signed, and build in time for number porting, which runs on the carrier's schedule rather than the project's.

Whichever of Google Workspace or Microsoft 365 the business already runs on needs reconnecting.

HubSpot: Calendar integration and the meetings tool

This connection is set up per user, not once for the whole account, so the setup time scales with headcount rather than staying fixed.

Whatever gateway takes payment against an invoice sits behind this line.

HubSpot: Payment links, or the accounting tool

This one follows directly from the invoicing decision made earlier: if invoicing ends up living outside HubSpot, the payment gateway naturally goes with it rather than staying behind.

Whichever provider was sending text messages behind vTiger sits here.

HubSpot: A marketplace SMS app

Confirm the replacement app actually logs each text to the record timeline; skip that check and reporting on texting simply disappears, with no error to flag that it happened.

Wherever customers have been logging in to view their own tickets needs a genuine replacement.

HubSpot: Customer portal

HubSpot's customer portal is a build in its own right, with its own permissions and its own branding to set up, not a checkbox inside the CRM migration. Confirm it is actually included in what you are signing up for before assuming customers keep the same self-service access they had before.

Any marketplace add-on installed directly into the vTiger instance falls under this line.

HubSpot: App Marketplace integrations, or no equivalent

A vTiger extension typically modifies the application itself, something HubSpot's platform does not permit at all, so the two are not comparable extension models. Some of these extensions have no HubSpot replacement whatsoever, and finding that out at the start of scoping avoids a promise later that nobody can actually keep, particularly relevant on a self-hosted instance where a contractor may have installed extensions years ago that nobody currently on staff fully understands.