-1.svg)
Key Takeaways
-
Test your HubSpot setup before go-live with written test scripts, so each check has a defined action, an expected result and an owner.
-
Use clearly labeled test records with addresses you control, and exclude them from reports, lists and marketing sends during testing.
-
Test the edge cases as well as the happy path: near misses, threshold values, repeat submissions and records that match no rule at all.
-
Grade each defect by severity, and agree before testing starts that any blocking defect means the launch date moves.
-
Collect sign-off from the owner of each area in writing, then make the go or no-go call against the agreed criteria.
A HubSpot portal can look finished in a demo and still misroute its first real lead. Acceptance testing before go-live is where you find that out, while the people affected are still the ones running the tests.
Why should you test your HubSpot setup before go-live?
You should test it because configuration that looks correct can still behave incorrectly with real data. A workflow may enroll the right records in a demo and the wrong ones when a field is blank. A form may create contacts but skip the owner. A report may count test deals as revenue. Each is cheaper to fix before launch than after it, when customers, reps and leadership already rely on the output.
What this means for you: put acceptance testing on the project plan as its own phase, with time reserved for fixing what it finds, rather than squeezing it into the last afternoon before launch.
How do you plan testing for your HubSpot setup before go-live?
Plan it in three parts: where you will test, what records you will test with and which scripts you will run.
Where to test: if your subscription includes a sandbox account, build and test there first, then repeat the critical tests in the live portal. Check what your own portal includes before you plan around it. Without a sandbox, test in the live portal with workflows and sends restricted to test records.
What to test with: create test records that are easy to find and remove. Give them a consistent marker in the name and use email addresses on a domain your team controls. Build a saved view that shows every test record, so you can exclude them from reporting and delete them once testing ends.
Which scripts to run: write each test as a short script with a starting state, an action, an expected result and an owner. "Submit the demo request form with a company email and a blank phone field" is a script. "Check the forms" is not.
Scripts should come from the decisions made earlier in the project. If the process map says a deal needs a confirmed budget holder before the proposal stage, a script should try to move a deal without one.
Questions to ask: Which business process would hurt most if it failed on day one, and do we have a script for it? Who will run each script, and who will judge whether it passed?
What should you test in your HubSpot setup before go-live?
Test each area where HubSpot creates, changes, routes or reports on data. The checklist below is a Markivis recommendation for a B2B setup covering marketing and sales. Add rows for service, commerce or custom objects if your implementation includes them.
At a glance: a go-live test checklist for a HubSpot setup, with the pass criterion and owner for each area.
|
Area |
What to test |
Pass criterion |
Owner |
|
Lead capture forms |
Submit each live form with test data, including blank optional fields |
Contact created or updated with the correct source, owner and lifecycle stage |
Marketing operations |
|
Lead routing |
Create test leads that match each routing rule, plus one that matches none |
Each lead reaches its intended owner, and the unmatched lead reaches a fallback owner |
Sales operations |
|
Deal pipeline |
Move a test deal through each stage, including one attempt to skip a stage |
Required properties are requested at the right stages, and skips behave as agreed |
Sales manager |
|
Workflows |
Enroll records that meet, nearly meet and fail the enrollment criteria |
Only qualifying records enroll, and each action runs once and in order |
HubSpot admin |
|
Email and subscriptions |
Send to internal test contacts with different subscription statuses |
Unsubscribed contacts receive nothing, and personalization falls back cleanly |
Marketing operations |
|
Integrations |
Create and update records in each connected system |
Data syncs in the agreed direction with no duplicates or overwritten values |
Systems owner |
|
Permissions |
A member of each role logs in and performs their daily tasks |
Each user can see and edit what the role needs, and nothing beyond it |
HubSpot admin |
|
Reports and dashboards |
Compare report totals against a known count of test records |
Totals match the test data exactly |
Revenue operations |
|
Migrated records |
Compare a sample of records with the source system |
Values, owners and associations match the source |
Data owner |
In the setups we test, the defects that reach go-live tend to sit in the path nobody scripted, such as a second form submission from an existing customer or a contact who unsubscribed last year.
What this means for you: assign every row an owner before testing starts, and do not count a row as passed until that owner has seen the result.
How do you test edge cases in a HubSpot setup before go-live?
You test them by building records that sit just inside, just outside or exactly on the line of each rule. Happy-path tests confirm that the design works. Edge-case tests show what it does with the records it was not designed around.
Two scripts for the same lead scoring workflow show the difference. The happy-path script creates a contact who meets every criterion and expects enrollment and a sales alert. The near-miss script creates a contact at a target company who meets every criterion except job level, and expects no enrollment and no alert. Only the second script proves the threshold holds.
We would build test inputs for six situations:
-
Near misses: a record that meets every enrollment or routing criterion but one, to confirm it stays out.
-
Threshold values: a lead score exactly at the handoff point, or a close date of today, to confirm which side of the rule each lands on.
-
Repeat arrivals: a second form submission from an existing customer, and a new contact at a company already in the portal.
-
Every entry point: the same lead created by a form, an import, a rep and each integration, since each path can set different properties.
-
Re-enrollment: a record that meets a workflow's criteria a second time.
-
Opt-outs: contacts who have unsubscribed, to confirm that no automated email reaches them.
Check each workflow's history after an edge-case test to confirm which records enrolled and which actions ran. A test is only complete when the outcome has been read, not just triggered.
What this means for you: write at least one edge-case script for each workflow and routing rule, and treat a silent failure as a blocking defect.
How do you make the go or no-go decision for a HubSpot go-live?
Make it against criteria agreed before testing begins, so the decision rests on evidence rather than on the pressure of the launch date. A practical starting point is three severity levels.
Blocking: the defect stops a core process, sends a wrong message to a customer or corrupts data. Any open blocking defect means no-go.
Major: the defect affects a process, but a documented workaround exists. Go-live can proceed if each major defect has an owner, a workaround and a fix date.
Minor: the defect is cosmetic or affects a path few users take. Log it for the first update after launch.
Measure readiness with two numbers: the share of scripts passed in the final test run and the count of open defects at each severity. Present both at a short go or no-go meeting with the owners from the checklist and the project sponsor. Each owner confirms their area in writing. Agree a fallback in the same meeting, such as keeping the old system available read-only and holding automated sends until the first day's records have been checked.
Questions to ask: Are there any open blocking defects, and if so, what moves the date? Has each area owner signed off in writing, and who has not?
The Bottom Line
A HubSpot launch is ready when written scripts have passed, edge cases have been tried on purpose, and each area owner has signed off with no blocking defect open. Agreeing severity levels before the first test runs keeps that call grounded in evidence.
The Markivis Approach
The script list is written while configuration is still underway, drafted from the signed process map and data decisions. The client's area owners run or observe those scripts, and the go or no-go meeting follows criteria agreed at the outset. Our HubSpot implementation services include test records, edge-case scripts and a defect log handed over with the portal.
-
Edge-case scripts are written for each workflow and routing rule.
-
Defects are graded by severity, with blocking defects resolved before launch.
Our ongoing HubSpot and lifecycle work with one client is described in the Slimstock case study. For the automation errors that testing is designed to catch, see our article on marketing automation mistakes that quietly drain your B2B pipeline.
