The Salesforce → HubSpot Migration Playbook

Why teams migrate from Salesforce to HubSpot

Salesforce is the deeper platform. HubSpot is the cleaner one. Teams that move from Salesforce to HubSpot usually share three patterns: the Salesforce build has become unmaintainable, the marketing team is on a separate tool that has stopped playing nicely with the CRM, and the operating cost of running Salesforce has outgrown the ROI it produces.

INSIDEA has migrated dozens of customers from Salesforce to HubSpot. The methodology resembles the standard HubSpot Migration Playbook but with deeper Discovery, more careful data work, and a phased cutover because the Salesforce footprint is usually larger.

When NOT to migrate

INSIDEA's honest read: not every Salesforce customer should move. If the build is heavily customised with Apex code, deep partner ecosystems (CPQ, FSL, Industries clouds), and 50+ integrations across an enterprise stack, the migration cost can outweigh the operating savings. We say so up front. The conversation that produces 'do not migrate' is the same conversation that earns the trust to migrate the customers who should.

Phase 1: Discovery, deeper than standard

Salesforce Discovery takes longer because the surface area is bigger. INSIDEA inventories every custom object, every Apex trigger, every Flow, every workflow rule, every integration, every report, and every Salesforce-licensed seat. The output is a written Migration Risk Assessment.

The Migration Risk Assessment covers

• Custom objects and how they map to HubSpot's standard objects plus custom object slots
• Apex and Flow logic and how each piece is replaced: HubSpot workflow, Operations Hub custom-coded action, retained as a separate microservice, or retired
• Integration map and the sync conflicts each integration carries today
• Reports and dashboards, ranked by who uses them and how often
• Permission model and how each role and profile maps onto HubSpot teams and permissions
• Data hygiene state: duplicates, stale records, missing fields, orphan activities

Phase 2: Architecture and stage gate

After Discovery, INSIDEA presents the architecture brief and the migration plan. This is a stage gate. The customer either commits to the migration with a signed plan or stops. Walking away here is acceptable. Walking away two months later is not. The clarity of the decision protects everyone.

Phase 3: Parallel build

HubSpot gets built while Salesforce keeps running. INSIDEA uses Operations Hub data sync to keep the two systems aligned during the build so the sales team is not stranded. Reports, dashboards, lifecycle stages, lead routing, all configured in HubSpot. Test users get HubSpot access early to surface gaps.

Phase 4: Phased cutover

Cutover happens by segment or team, not all at once. The first team moves to HubSpot for the first window with INSIDEA on standby. Their pipeline activity gets watched. Gaps get fixed in real time. Once that team is stable, the next team moves. By the end of the cutover, the whole org is on HubSpot and Salesforce is read-only.

Phase 5: Salesforce retirement

Salesforce stays read-only for 90 days after cutover. That gives the team a fallback if something is missing and gives finance time to wind down licenses. After 90 days of zero writes to Salesforce, the org commits and Salesforce gets archived. INSIDEA pulls a final export and stores it for the customer.

The five sync conflicts that always show up

Across dozens of Salesforce migrations these are the five conflicts that surface every single time during the parallel-build phase. INSIDEA resolves them in the Architecture Brief so they are not surprises at cutover.