How are teams structuring lifecycle stages in HubSpot after multiple acquisitions or CRMs?

Hi everyone,

I’m curious how teams are structuring lifecycle stages and pipelines in HubSpot when bringing together multiple companies or CRMs.

I’m currently working on a project where we are consolidating sales reporting across a large group of acquired companies, and one of the biggest challenges is standardizing lifecycle stages while still preserving the context of each company’s original pipeline.

Some questions I’d love to hear perspectives on:

• Do you standardize lifecycle stages across all business units or allow variations per team?
• How do you handle legacy deal stages when migrating multiple CRMs into HubSpot?
• Do you rely more on custom properties or lifecycle stages for reporting consistency?
• Any best practices for maintaining clean reporting when different teams sell very different products?

Curious to hear how others have solved this, especially in organizations with multiple brands, acquisitions, or complex sales motions.

Thanks in advance for sharing your experiences.

Hey @nidaateeq,
Thanks for posting in the Community!
I’d like to tag in some CRM experts to see if they can get the conversation going!
@karstenkoehler, @Josh, @danmoyle - any thoughts to get us started?
Shane, Senior Community Moderator

Hi @nidaateeq,

Happy to help here!

“Do you standardize lifecycle stages across all business units or allow variations per team?”

In general, I’d advise to use one shared definition across business units / teams, purely because it reduces complexity and because HubSpot only offers one set of lifecycle stage values out of the box anyway.

However, if the goal is to easily see whether a contact is a SQL towards one business unit and a customer towards another, then there is no way around creating custom lifecycle stage properties and the workflows that take care setting the corresponding date stamps.

“How do you handle legacy deal stages when migrating multiple CRMs into HubSpot?”

Store the information when a deal entered those legacy stages in custom date properties, or safely stowed away in a csv file should anyone ever need them again - but don’t create them as actual stages in HubSpot. They’ll be visual clutter in workflows, for users and constantly raise questions.

“Do you rely more on custom properties or lifecycle stages for reporting consistency?”

If you want HubSpot’s funnel reports, you must use HubSpot’s default lifecycle stages. There are a few creative ways to get conversion rate reports without funnel reports, but if you’re looking for the visual experience from % on stage to stage changes, you’re “stuck” with the default fields.

Custom properties are needed, see above, if you want to track lifecycle stage per business unit / team.

“Any best practices for maintaining clean reporting when different teams sell very different products?”

That depends on the reports you’d like to get. In some cases, it can make sense to create a custom product object, which will enable you to have a lot more flexibility in reporting.

Best regards

Hi @nidaateeq! +1 for the advice from my friend @karstenkoehler here. I’m going to add some of my own flavor of perspective just so you have additional help, hopefully.

I’m going to go right to the reporting question. I agree with what Karsten said about your other questions, so no need to expand there. So… for organizations where teams sell very different products or motions, clean reporting usually hinges on a clear dimensional model. Here’s how I’d picture that:

  • Standard lifecycle for where the buyer is in the journey (universal).
  • Pipelines and stages for how the team executes their process (team‑specific).
  • Custom properties for who and what: brand, BU, market, product, ACV band, sales motion, etc.

Then I’d try to build a rleatively simple and scalable reporting stack. I’d recommend global executive reports: Lifecycle funnel, revenue, and win rate sliced by brand/BU and product family using custom properties. Then for team‑level reports, I’d lean into pipeline‑specific stage conversion and velocity within each pipeline.

As for data governance, I’d consider quarterly audits. For me, it’s a) Stage usage (are stages skipped or misused?); b) Lifecycle consistency (do “Opportunities” always have an open deal?); and c) Property hygiene (brand/BU populated, no “unknown” in key segment fields).
​

One simple example: all brands share Lead => MQL => SQL => Opportunity => Customer, but Brand A has a 5‑stage enterprise pipeline and Brand B has a 3‑stage self‑serve pipeline; executives still get a single funnel view by lifecycle and can filter by brand, while each team sees a pipeline tuned to its reality.

I hope that helps!