I’m leading a HubSpot migration from an in-house CRM to HubSpot (Professional) for a payment company (B2C + B2B).
Historically, HubSpot was used inconsistently:
- One-off data imports via API
- No lifecycle automation
- Static custom properties created without clear ownership
- No reliable sync or reporting As a result, the portal is messy.
We don’t have a sales team, lifecycle should be driven by behavioral data (signup, KYC, activation, transactions), but this data isn't synced with HubSpot.
I’m looking for guidance on where to start and how to structure the work:
1. Data audit & cleanup
Recommended approach to auditing existing objects, properties, and imports.
2. What to prioritise first (contacts, properties, lifecycle, workflows)?
3. Property mapping
How to decide which properties to migrate vs drop?
Whether to document business use cases per property before migration?
3. Lifecycle automation
Best practices for lifecycle stages without sales team
4. Lead scoring for B2C
Is lead scoring useful without sales?
5. Integrations prioritisation
Jira (tickets), Front (team shared inbox), Slack, Power BI
Which integrations should wait until data is cleaned and standardised
Goal: rebuild HubSpot as a clean system of record for marketing, lifecycle communication, and high-level reporting, automate marketing proccess.
Any structured frameworks or practical guidance would be greatly appreciated.
Hi @Gulnur! Messy HubSpot legacy portals are definitely common. Honestly, it's probably the same over all CRM platforms. But I digress. Here's a bit from my brain and additional resources after several years of client work at HubSpot partners. I also managed a portal in-house for years early on.
1. Data audit and cleanup. Let's start at the beginning. I like that you put audit at the top of your list. We can't imporve what we don't nderstand and document. So first, focus the audit on “what do we need for lifecycle, comms, and reporting,” not “what do we already have.”
Recommended steps: First, pull extracts of contacts, companies, custom properties, lists, workflows, and integrations, and calculate basic data hygiene metrics (record counts by type, duplicate rate, key property fill rates, bounce/inactive rates). Next, identify obviously dead data: contacts with long‑term inactivity/bounces, properties with near‑zero fill rates or unknown purpose, and unused lists/workflows; tag these for archival or deletion after a grace period. Then work to standardize naming conventions for properties, lists, and workflows (an example might be prefixes like sys_, beh_, b2c_, b2b_) and reorganize property groups to reflect domains such as KYC, activation, and plan. Finally, define an ongoing hygiene cadence (monthly new‑data reviews, quarterly critical‑field audits, annual full review) so this doesn’t become a one‑off cleanup.
A best practice I've learned is that it's usually worth creating a temporary “Parking Lot” group for ambiguous legacy fields and locking them for new use while you design the new schema.
2. What to prioritize first. In a rebuild for a product‑led/payment environment with no sales team, the sequence should reflect dependencies. So let's dive into some good practices here.
Priority order:
Core data model (objects + properties): Define what a contact, company/merchant, and any key custom object (accounts, cards, wallets, transactions if applicable) represent, plus which system is the system of record for each field.
Lifecycle model (stages + statuses): Design lifecycle stages and any supporting status fields around product behavior (signup → KYC → activated → transacting → dormant/churned).
Data ingestion and syncs: Implement the minimal viable integrations needed to populate lifecycle‑critical fields (signup events, KYC state, activation, transaction milestones).
Workflows and automation: Only after lifecycle and data flows are defined, build workflows for lifecycle progression, comms triggers, and enrichment.
Reporting and dashboards: Finally, define a small set of executive KPIs (signup→KYC completion, activation rate, active vs dormant, cohort retention) and build reports around those.
Contacts, properties, and lifecycle are effectively one bundle: treat them as a single design phase before touching large‑scale imports or complex workflows.
3. Property mapping and documentation. The goal here is of course to end with a lean, well‑owned schema that maps tightly to business questions.
With that as the goal, here's what I'd decide what to migrate.
For each source property, answer:
What decision or process uses this field today or will use it after the migration?
Is this data available elsewhere in a cleaner system of record?
Do we need it for segmentation, lifecycle, personalization, or reporting in the next 12–18 months?
Mark each as Keep (Core), Keep (Archive / read‑only), or Drop. Fields with unknown purpose, low fill rate, or no clear use case should default to Drop or Archive, not Keep.
Let's lay out some documentation practices (crediting this blog with inspiring this list). Create a simple data dictionary that includes for each property:
Label and internal name
Description and business use case
Object (contact, company, custom) and data type
Owner (team or role) and system of record (e.g., app DB vs HubSpot)
Is it required on create? Is it editable by users or only via integrations/workflows?
Make sure to group properties functionally (Identity, Consent, KYC, Product Plan, Usage, Risk/Fraud flags) and apply consistent naming conventions. By the way, documenting business use cases per property before migration is very helpful in this scenario; it prevents recreating the current mess and makes future audits faster.
4. Lifecycle automation without a sales team. You can still use lifecycle stages; they just become product‑driven instead of sales‑driven. Redefine stages to match your funnel, for example:
Subscriber – marketing opt‑in only.
Lead – created an account / started signup.
MQL – completed KYC or reached a key intent signal (e.g., linked bank).
Opportunity – first successful transaction or submitted application for higher‑tier product.
Customer – meets your definition of “activated” (e.g., N transactions or volume threshold).
Evangelist – high NPS, referrer, or VIP usage.
Note: HubSpot does allow you to customize these labels, so you don't have to stick with the standard naming.
Once that's in place, you can drive lifecycle changes purely from events and product fields. Workflows listen for events/properties such as “KYC status = approved,” “first transaction date is known,” or “no transactions in X days” and update the lifecycle stage accordingly.
Then, make lifecycle bi‑directional where useful: churn/dormancy moves a contact back to a “Dormant customer” equivalent using a separate flag or custom lifecycle if you need more nuance.
Support lifecycle with additional status fields if needed, and keep lifecycle itself high‑level so reporting stays clear.
5. Lead scoring for B2C without sales. Lead scoring can still be useful, but it should feed automation and prioritization, not SDR queues. You can use scoring to define segments for campaigns (high‑intent but not yet activated, at‑risk of churn), tTrigger lifecycle emails / in‑app nudges when contacts cross score thresholds, and support marketing decisions and experimentation (like who gets higher‑touch onboarding).
Here's how I'd think about structuring scoring. First, focus almost entirely on behavioral and product signals.
Positive: app logins, KYC completion, card added, first/third/10th transaction, high volume or frequency, engagement with key lifecycle emails.
Start simple with 2–3 tiers (score bands like “Cold / Warm / Hot activation candidates”), validate against actual activation/churn behavior, then refine. If bandwidth is tight, postpone scoring until your lifecycle model and key events are reliably in HubSpot. Scoring is only as good as the underlying event data. (I bolded that because I've seen too many well-meaning folks have false starts with bad data.)
6. Integration prioritization (Jira, Front, Slack, Power BI). So, this is an area I don't have a lot of experience. I didn't want to give you bad advice. I looked up some information with various search and AI tools, but I don't really understand, so I won't speak out of turn. Hopefully someone else can help, or maybe you can find something to solve it for you.
I hope that helps!
Did my answer help? Please "mark as a solution" to help others find answers. Plus I really appreciate it!
I use all tools available to help answer questions. This may include other Community posts, search engines, and generative AI search tools. But I always use my experience and my own brain to make it human.
Hi @Gulnur! Messy HubSpot legacy portals are definitely common. Honestly, it's probably the same over all CRM platforms. But I digress. Here's a bit from my brain and additional resources after several years of client work at HubSpot partners. I also managed a portal in-house for years early on.
1. Data audit and cleanup. Let's start at the beginning. I like that you put audit at the top of your list. We can't imporve what we don't nderstand and document. So first, focus the audit on “what do we need for lifecycle, comms, and reporting,” not “what do we already have.”
Recommended steps: First, pull extracts of contacts, companies, custom properties, lists, workflows, and integrations, and calculate basic data hygiene metrics (record counts by type, duplicate rate, key property fill rates, bounce/inactive rates). Next, identify obviously dead data: contacts with long‑term inactivity/bounces, properties with near‑zero fill rates or unknown purpose, and unused lists/workflows; tag these for archival or deletion after a grace period. Then work to standardize naming conventions for properties, lists, and workflows (an example might be prefixes like sys_, beh_, b2c_, b2b_) and reorganize property groups to reflect domains such as KYC, activation, and plan. Finally, define an ongoing hygiene cadence (monthly new‑data reviews, quarterly critical‑field audits, annual full review) so this doesn’t become a one‑off cleanup.
A best practice I've learned is that it's usually worth creating a temporary “Parking Lot” group for ambiguous legacy fields and locking them for new use while you design the new schema.
2. What to prioritize first. In a rebuild for a product‑led/payment environment with no sales team, the sequence should reflect dependencies. So let's dive into some good practices here.
Priority order:
Core data model (objects + properties): Define what a contact, company/merchant, and any key custom object (accounts, cards, wallets, transactions if applicable) represent, plus which system is the system of record for each field.
Lifecycle model (stages + statuses): Design lifecycle stages and any supporting status fields around product behavior (signup → KYC → activated → transacting → dormant/churned).
Data ingestion and syncs: Implement the minimal viable integrations needed to populate lifecycle‑critical fields (signup events, KYC state, activation, transaction milestones).
Workflows and automation: Only after lifecycle and data flows are defined, build workflows for lifecycle progression, comms triggers, and enrichment.
Reporting and dashboards: Finally, define a small set of executive KPIs (signup→KYC completion, activation rate, active vs dormant, cohort retention) and build reports around those.
Contacts, properties, and lifecycle are effectively one bundle: treat them as a single design phase before touching large‑scale imports or complex workflows.
3. Property mapping and documentation. The goal here is of course to end with a lean, well‑owned schema that maps tightly to business questions.
With that as the goal, here's what I'd decide what to migrate.
For each source property, answer:
What decision or process uses this field today or will use it after the migration?
Is this data available elsewhere in a cleaner system of record?
Do we need it for segmentation, lifecycle, personalization, or reporting in the next 12–18 months?
Mark each as Keep (Core), Keep (Archive / read‑only), or Drop. Fields with unknown purpose, low fill rate, or no clear use case should default to Drop or Archive, not Keep.
Let's lay out some documentation practices (crediting this blog with inspiring this list). Create a simple data dictionary that includes for each property:
Label and internal name
Description and business use case
Object (contact, company, custom) and data type
Owner (team or role) and system of record (e.g., app DB vs HubSpot)
Is it required on create? Is it editable by users or only via integrations/workflows?
Make sure to group properties functionally (Identity, Consent, KYC, Product Plan, Usage, Risk/Fraud flags) and apply consistent naming conventions. By the way, documenting business use cases per property before migration is very helpful in this scenario; it prevents recreating the current mess and makes future audits faster.
4. Lifecycle automation without a sales team. You can still use lifecycle stages; they just become product‑driven instead of sales‑driven. Redefine stages to match your funnel, for example:
Subscriber – marketing opt‑in only.
Lead – created an account / started signup.
MQL – completed KYC or reached a key intent signal (e.g., linked bank).
Opportunity – first successful transaction or submitted application for higher‑tier product.
Customer – meets your definition of “activated” (e.g., N transactions or volume threshold).
Evangelist – high NPS, referrer, or VIP usage.
Note: HubSpot does allow you to customize these labels, so you don't have to stick with the standard naming.
Once that's in place, you can drive lifecycle changes purely from events and product fields. Workflows listen for events/properties such as “KYC status = approved,” “first transaction date is known,” or “no transactions in X days” and update the lifecycle stage accordingly.
Then, make lifecycle bi‑directional where useful: churn/dormancy moves a contact back to a “Dormant customer” equivalent using a separate flag or custom lifecycle if you need more nuance.
Support lifecycle with additional status fields if needed, and keep lifecycle itself high‑level so reporting stays clear.
5. Lead scoring for B2C without sales. Lead scoring can still be useful, but it should feed automation and prioritization, not SDR queues. You can use scoring to define segments for campaigns (high‑intent but not yet activated, at‑risk of churn), tTrigger lifecycle emails / in‑app nudges when contacts cross score thresholds, and support marketing decisions and experimentation (like who gets higher‑touch onboarding).
Here's how I'd think about structuring scoring. First, focus almost entirely on behavioral and product signals.
Positive: app logins, KYC completion, card added, first/third/10th transaction, high volume or frequency, engagement with key lifecycle emails.
Start simple with 2–3 tiers (score bands like “Cold / Warm / Hot activation candidates”), validate against actual activation/churn behavior, then refine. If bandwidth is tight, postpone scoring until your lifecycle model and key events are reliably in HubSpot. Scoring is only as good as the underlying event data. (I bolded that because I've seen too many well-meaning folks have false starts with bad data.)
6. Integration prioritization (Jira, Front, Slack, Power BI). So, this is an area I don't have a lot of experience. I didn't want to give you bad advice. I looked up some information with various search and AI tools, but I don't really understand, so I won't speak out of turn. Hopefully someone else can help, or maybe you can find something to solve it for you.
I hope that helps!
Did my answer help? Please "mark as a solution" to help others find answers. Plus I really appreciate it!
I use all tools available to help answer questions. This may include other Community posts, search engines, and generative AI search tools. But I always use my experience and my own brain to make it human.
I can’t find enough words to express my gratitude. I had all these questions in my mind, and after I put them on paper and started searching for answers on the internet, it was unsuccessful.
I’m very grateful, and thank you so much. I’ll start this process step by step based on your recommendations. I may have questions along the way. I’m happy to have such a helpful community here.
@BérangèreL you always make my day! Thank you for all the support.
Did my answer help? Please "mark as a solution" to help others find answers. Plus I really appreciate it!
I use all tools available to help answer questions. This may include other Community posts, search engines, and generative AI search tools. But I always use my experience and my own brain to make it human.
Hi @Gulnur and thank you so much for sharing such a thorough overview of your migration project with the HubSpot Community!
I’d love to connect you with some of our top experts who have a wealth of experience with migrations. @danmoyle, @HubDoPete and @TomM2 do you have any insights or tips you could share with @Gulnur, please?
Thank you all in advance for your valuable contribution and have a fantastic day! Bérangère
Loop Marketing is a new four-stage approach that combines AI efficiency and human authenticity to drive growth.