For HubSpot app teams & development agencies
Migrate the card.
Keep the action working.
Move one classic CRM card to a React app card, with the backend changes and repeatable checks its business actions need.
Delegate a defined implementation. Your team reviews the patch, accepts it in a test installation, and controls the customer release.
Plan around October 31, 2026. HubSpot says classic cards leave customer views on that date. Its remaining migration APIs and UI run until December 1. Official migration timeline ↗
“This card loads a customer record and its button updates our backend. We need that flow working in the replacement.”
A concrete migration detail
Keep the request contract intact.
Official converter source
Synthetic inputs · SDK-boundary checks
- 01 / Data
Preserve existing query fields.
A data URL may already carry a tenant or routing parameter. The converter must preserve that value when adding CRM context and record properties.
- 02 / Action
Handle the new body format.
The official converter sends action data as JSON. Legacy POST, PUT and PATCH handlers may expect form-encoded data. Agree and test both paths while the cards coexist.
- 03 / Acceptance
Check the business result.
Use known records to assert the fetched fields, outgoing action parameters and resulting backend state. Then verify the replacement in a test installation.
Configured: https://example.com/card?tenant=alpha
Original: https://example.com/card?tenant=alpha?userId=7&…
Parsed: tenant = "alpha?userId=7"; userId = absent
Required: tenant = "alpha"; userId = "7"Observed in the official converter source on October 6, 2026. We executed its request-building module with synthetic context and a stubbed HubSpot SDK. The configured query value was altered and the separate userId parameter was lost. The proposed fix preserves the query and fragment; eight added URL scenarios and the full 256-test converter suite pass. Customer staging checks cover HubSpot-injected metadata, request signatures, and the live business action.
The $1,800 pilot
A reviewable patch.
A defined release path.
For one app already on HubSpot’s projects framework, version 2025.2 or newer, with editable Node.js/TypeScript or Python endpoints.
Whole-app platform migration, OAuth changes, extra cards and additional integrations are scoped separately. The first brief establishes which parts your app needs.
- 01
Agree the behavior
Confirm one classic card in one CRM location, one data endpoint, one action endpoint, expected fields and business outcomes. Set the acceptance checks, delivery date and one revision before payment.
- 02
Implement and exercise it
Deliver the React card and backend patch, using the official converter where suitable. Add repeatable checks for URL/context preservation, old/new payloads, the action outcome, and agreed error cases.
- 03
Hand over the release
Provide observed contract-test results, configuration changes, legacy-to-new card mapping, and staging acceptance steps. Your operator deploys to the test installation and performs the agreed live checks.
- 04
Switch the customer view
After staging acceptance, your operator follows the documented feature-flag and view-swap sequence, then checks the migration completion status. HubSpot describes view swapping as a one-way change; this puts acceptance before the switch.
The inputs that make scoping quick
A sanitized card definition, example data/action requests and responses, backend language, app project version, and target release date. Source access, a test installation, staging endpoints and an authorized customer operator are arranged for the agreed work.
Copyable card example: Open a company report using its public ID and the current viewer’s email — React source, a card manifest, and repeatable synthetic checks.
Existing capabilities: PostgreSQL approval-to-ERP implementation · Executed request/retry checks. Both are self-initiated engineering samples.
Start with one card
What must still work
after your migration?
Card behavior. Backend language. Target release date.