Good Morning/Afternoon/Evening all, I have a question regarding Sandbox/Prod and Prod/Sandbox migrations. Hoping you all might have some thoughts.
We are trying to implement a proper development workflow using the HubSpot Sandbox environment but are running into a fundamental issue around ID consistency between Production and Sandbox.
Our Goal
We want to adopt a workflow where:
We are trying to implement a proper development workflow using the HubSpot Sandbox environment but are running into a fundamental issue around ID consistency between Production and Sandbox.
Our Goal
We want to adopt a workflow where:
- Production data and configuration can be copied into a HubSpot Sandbox environment.
2. Development and testing occur in Sandbox.
3. Configuration Changes are then safely promoted back to Production. (We are not pushing Data back to Prod from Sandbox)
This works well conceptually for configuration and development, but we are running into issues because IDs are regenerated in any new environment during migration, which breaks integrations and schema references.
Current Architecture
Our environment has several integrations where we rely heavily on HubSpot internal IDs, including:
3. Configuration Changes are then safely promoted back to Production. (We are not pushing Data back to Prod from Sandbox)
This works well conceptually for configuration and development, but we are running into issues because IDs are regenerated in any new environment during migration, which breaks integrations and schema references.
Current Architecture
Our environment has several integrations where we rely heavily on HubSpot internal IDs, including:
- Object IDs
- Record IDs
- Association Labels
- Schema IDs
These IDs are used in:
- API calls to external systems
- Cross-system record matching
- Integration logic
- Data synchronization processes
Because of this, ID stability is critical to maintain continuity across systems.
The Problem
When copying Production → Sandbox:
HubSpot generates new IDs for objects, records, schemas, and association labels.
- As a result, references used by integrations no longer match.
- Any development or testing done in Sandbox cannot reliably mirror the Production integration behavior.
This makes it difficult to validate:
- API integrations
- association logic
- schema updates
- cross-system record linking
Tools We Currently Use
We do have the Datawarehouse.io HubSpot Portal Tool Kit, which helps with portal management and migrations. However, it does not solve the ID remapping issue, since the underlying HubSpot objects and records still receive new IDs when created or copied.
What We Are Trying to Determine
We are looking for best practices or architectural patterns for handling this situation, such as:
How other teams handle ID differences between Sandbox and Production
Whether anyone has implemented a stable external identifier strategy (e.g., custom unique IDs)
Ways to maintain reliable cross-system references without relying on HubSpot-generated IDs
- Any tooling or workflows that allow safe promotion of schema/config changes while preserving integration stability
Questions for the Community
- How do teams using HubSpot Sandbox handle ID regeneration between environments when integrations depend on those IDs?
- Is the recommended approach to avoid HubSpot IDs entirely for integrations and rely on custom external IDs instead?
- Are there migration or deployment workflows that help maintain consistent references for schemas, associations, and objects across environments?
Any insight into real-world workflows or integration architecture would be greatly appreciated.