RevOps Playbook: Integration QA, Cutover, and Change Management for HubSpot–Salesforce

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

Most integration failures are not technical—they are operational. Without disciplined QA, a controlled cutover, and structured change management, even a good HubSpot–Salesforce design will produce drift, broken automations, and reporting anomalies. This playbook defines how to test, launch, and evolve your integration so it stays reliable as your go‑to‑market changes.

QA Strategy and Environments

Use a Salesforce sandbox and a HubSpot sandbox wherever possible. Mirror essential configuration: objects, fields, picklists, pipelines, and inclusion lists. Seed both with realistic test data and owners so you can exercise routing and permissions. Avoid using production data except for read‑only comparisons.

Build a regression test suite that covers the core stories: inbound lead to MQL, MQL to SQL via opportunity creation, contact owner reassignment, company deduplication, and deal stage progression. For each story, specify preconditions, actions, expected field changes, lifecycle dates, and activities. Automate where practical using a testing harness or iPaaS flows that reset records between runs.

Data Migration vs. Sync

If you are migrating historical data, treat migration separately from ongoing sync. Freeze non‑essential automations, perform field‑by‑field validation against samples, and reconcile counts. Only after the migration stabilizes should you enable bi‑directional sync. Mixing both increases risk and obscures root causes.

Cutover Plan

Time your cutover to minimize business impact—often a weekend or low‑activity window. Announce a freeze on high‑risk automations and define a blackout period for mass list updates. Prepare a step‑by‑step runbook: disable conflicting workflows, take pre‑cutover snapshots, enable integration components in order, and run smoke tests with a prepared checklist.

If something goes wrong, have a rollback plan. That plan should include disabling write‑backs, restoring critical mappings from version control, and reverting inclusion lists. Communicate rollback immediately to sales and marketing with plain guidance on what to expect.

Post‑Cutover Hypercare

In the first two weeks, monitor error rates, duplicate creation, lifecycle drift, and reconciliation reports daily. Hold a short stand‑up to triage top issues. Set a temporary SLA that prioritizes integration stability: reduce configuration changes outside the core team and route conflicting requests to backlog until the system settles.

Change Management Process

Treat integration configuration as code: version field mappings, lifecycle rules, and inclusion lists. Use pull requests with reviewers from RevOps, Sales Ops, and Marketing Ops. Tag changes with a release number, update documentation, and link to the risk assessment.

Communicate changes in human terms: what users will see differently, when, and why. Pair a technical changelog with quick reference cards for sellers and marketers showing new fields, statuses, or behaviors.

Risk Assessment Template

Before releasing a change, score risk based on blast radius (objects and automations touched), reversibility (easy rollback or not), and business calendar (quarter end, major campaign). High‑risk changes require sandbox validation, stakeholder sign‑off, and a scheduled release window with on‑call coverage.

Documentation and Runbooks

Maintain a living runbook with: environments and credentials, objects and fields in scope, SoR decisions, lifecycle event definitions, inclusion list logic, error classes and owners, and links to dashboards. Good documentation shortens outages by making it obvious who owns what.

Training and Adoption

Train sellers and marketers on what changed and why. Focus training on workflows: how MQLs appear in queues, when Tasks are created, how to interpret lifecycle, and how to request fixes. Adoption depends on clarity and quick support in the first month.

Continuous Improvement

Each month, review the top five incidents and the most frequent sources of confusion. Propose and ship one systemic fix—tighten a validation rule, tune inclusion logic, or improve an alert. Publish before/after metrics to prove value and reinforce investment in integration quality.

FAQ

How do we test without spamming sales?

Use sandbox environments and test owners. In production, route test records to a special owner and exclude them from queues and sequences using inclusion rules.

What if our marketing calendar can’t accommodate a long freeze?

Shorten the freeze by limiting scope and doing smaller, more frequent releases. Run A/B cutovers for isolated components instead of an all‑at‑once switch.

Who should approve risky changes?

At minimum, RevOps plus the downstream function most affected (Sales Ops for lead routing, Marketing Ops for lifecycle thresholds). For changes that impact revenue reporting, include Finance.

How do we know the cutover succeeded?

Your smoke tests pass, reconciliation variance is within threshold after the freshness window, error rates remain low, and sellers report that queues and activities look normal.

When can we re‑enable paused automations?

After reconciliation is stable for at least 48 hours and error rates remain below target. Re‑enable in phases and watch signals between each stage.