HubSpot legacy CRM cards: how to audit your integrations before 31 October 2026
An integration can keep exchanging data correctly while an important part of its user interface is about to disappear. That is the risk facing organisations that still depend on HubSpot's legacy CRM cards.
HubSpot says legacy CRM cards built with its CRM Extensions API will stop rendering in CRM records on 31 October 2026. If a card is affected, the practical response is to identify its owner, record the work users perform through it, rebuild or replace it with a React-based App Card, test the replacement and complete the view migration before the deadline.
Vivato builds bespoke and semi-bespoke CRM systems for UK organisations, including integrations with existing business software. This guide is for CRM owners, operations leaders and technical teams that need to establish whether the change affects them and turn a platform deadline into a controlled piece of integration work.
What is a legacy HubSpot CRM card?
A legacy CRM card is a panel added to a HubSpot CRM record by an older public or private app using the CRM Extensions API. It can display information from another system and may let a user perform actions through links, webhooks, buttons or embedded interfaces.
For example, a card on a company record might show an account balance from an ERP system. A card on a ticket might retrieve service entitlement data. A bespoke integration could use a card to open an external quoting, fulfilment or case-management workflow without making the user leave HubSpot first.
The issue is not that every HubSpot integration will stop working. HubSpot's notice applies specifically to legacy cards created through the older CRM Extensions API. HubSpot states that UI Extensions built with Projects are not affected by this particular retirement. An integration that only synchronises data in the background may also be outside its scope.
That distinction matters. The audit should identify affected interface components rather than labelling the entire HubSpot estate as obsolete.
What changes on 31 October 2026?
HubSpot says classic CRM cards will stop rendering in CRM records after the sunset date, and the supporting legacy endpoints will be removed. A card that employees use today could therefore vanish from the relevant contact, company, deal or ticket view even if the external application and some background data flows continue to operate.
The business impact depends on what the card does. Its loss might remove a convenient summary, or it might block a step that users rely on to quote, check an account, assess a service case or move work into another operational system.
Treat the deadline as a workflow risk, not just a developer task. A technically small component can be operationally important when it sits at a frequent decision point.
How can you tell whether your organisation is affected?
Start with visible CRM views, then trace each unfamiliar panel back to its application and technical owner. Do not rely only on a list of installed apps. The people using a card every day may understand its purpose better than the person who originally authorised the installation.
Use the following evidence sources:
- Review the right sidebar and other configured areas on representative contact, company, deal and ticket records.
- Inventory public apps, private apps and bespoke integrations connected to each HubSpot account.
- Ask sales, service and operations users which panels display external data or launch actions.
- Check app configuration and source code for legacy card definitions or calls to the older CRM Extensions API.
- Contact the vendor or developer responsible for any component that cannot be classified internally.
If your organisation uses a Marketplace app, the app provider will normally own the technical migration. You still need evidence that a replacement is planned and clarity on any change to permissions, behaviour or rollout. If your organisation commissioned a private or bespoke app, responsibility is more likely to sit with your internal team or development partner.
A practical HubSpot legacy CRM card audit
Create one line per card, not merely one line per app. A single application can expose several cards with different users, record types and levels of importance.
| Audit field | What to record | Why it matters |
|---|---|---|
| Card and app | Visible card name, app name and technical identifier | Prevents similarly named components from being confused |
| CRM location | Contact, company, deal, ticket, help desk or another view | Shows where testing and view migration are required |
| Business purpose | The decision, information or action the card supports | Reveals the operational consequence of losing it |
| Users and frequency | Teams, roles and approximate usage pattern | Helps prioritise high-volume workflows |
| Data source | External system, API and key records or fields | Defines dependencies and test data needs |
| Actions | Buttons, links, webhooks, forms or embedded interactions | Identifies behaviour that a visual copy alone may miss |
| Owner | App vendor, internal product owner and technical maintainer | Makes accountability explicit |
| Current technology | Legacy CRM card, App Card, unknown or no card | Separates confirmed work from investigation |
| Replacement route | Migrate, redesign, remove or replace the app | Turns discovery into a decision |
| Test evidence | Scenarios, permissions, results and sign-off owner | Supports a controlled release |
1. Classify the business impact
Rate each confirmed legacy card according to the effect of losing it:
- Critical: users cannot complete a core process or access information needed for a time-sensitive decision.
- High: a common workflow becomes substantially slower, more manual or more error-prone.
- Medium: useful context disappears, but an established alternative remains available.
- Low: the card is rarely used, duplicates other information or can be retired without material disruption.
This impact rating should drive delivery order. Technical complexity alone is a poor prioritisation method because a simple but heavily used card may deserve attention before a complex low-use component.
2. Decide whether to reproduce, redesign, remove or replace
Migration does not automatically mean recreating every card exactly as it is.
Reproduce the existing behaviour when it is well understood, useful and time is limited. HubSpot provides migration guidance and a converter example intended to help developers create a close replacement.
Redesign when the current card makes users open several screens, exposes too much information or reflects an outdated process. Modern App Cards offer a chance to simplify the interaction, but additional scope increases testing and change-management needs.
Remove a card when evidence shows that it is unused, duplicated or tied to a process that has already ended. Confirm the decision with actual users before deleting it.
Replace the wider app or integration when the card is only one symptom of unsupported technology, unclear ownership or persistent reliability problems. This is a broader investment decision and should not be rushed solely to meet the card deadline.
Vivato's approach to product modernisation can help organisations assess whether to update a component incrementally or address a wider legacy-system risk.
3. Build a test plan around user outcomes
HubSpot recommends building and testing the replacement App Card in an isolated test account before it is added to the live app. The test plan should go beyond confirming that the card appears.
For each card, test:
- the correct CRM objects and views;
- users with different roles and permissions;
- records with complete, partial and missing external data;
- each button, link, webhook and embedded action;
- authentication expiry and re-authorisation where relevant;
- API errors, timeouts and unavailable external services;
- help desk behaviour when a ticket card is involved;
- the old-to-new view swap; and
- monitoring, support and rollback arrangements around release.
HubSpot notes that once its card view swap has started, it cannot be reversed. That makes representative testing and an agreed release decision especially important. A separate workaround for the business process should also be documented in case an unrelated issue emerges after release.
What should you ask an app vendor or CRM development partner?
An assurance such as “we are aware of the deadline” is not enough for a business-critical integration. Ask for specific answers:
- Does our installed version use any legacy CRM cards?
- Which record types, views and user workflows are affected?
- Who owns the migration and what is the target release date?
- Will the replacement preserve every current action and data point?
- Are any permissions, scopes or authentication steps changing?
- How will our configuration and representative data be tested?
- What user communication or training will be needed?
- How will errors be monitored after the view swap?
- Is the migration included in our existing agreement, or is separate work required?
- What is the fallback business process if the card is unavailable?
When a card connects HubSpot to a bespoke operational platform, review the complete interface boundary as well as the visible component. Vivato's API and third-party integration services cover the design, delivery and ongoing maintenance of connections between CRM, finance, operations and other systems.
Should you use the deadline to replace your CRM?
Usually, no. A legacy CRM card retirement is a reason to inspect an integration, not automatic evidence that HubSpot or the surrounding CRM strategy is wrong.
A focused migration is likely to be proportionate when the wider platform still fits, users are satisfied and the integration has a clear owner. Consider broader change when the audit uncovers several connected problems, such as unsupported apps, fragmented data, repeated manual work, poor reporting or business processes that no longer fit the CRM.
The alternatives may include reconfiguring HubSpot, rebuilding the integration, adding a semi-bespoke operational layer or developing a more tailored CRM. Vivato's overview of custom CRM and operational systems explains how connected software can support complex processes without assuming that every organisation needs a fully bespoke replacement.
What should happen next?
By late August 2026, organisations have limited room for an open-ended discovery exercise. A sensible immediate plan is to complete the inventory, obtain vendor commitments, prioritise affected workflows and schedule testing well before the final week of October.
The most useful output is not a technical list of apps. It is an owned plan that connects each legacy card to a business process, a replacement decision, test evidence and a release date.
Vivato can help UK organisations assess bespoke HubSpot integrations, modernise affected components and decide whether a focused card migration or a wider CRM improvement is justified. The first conversation should establish what is affected and who owns it, without presuming that a larger rebuild is necessary.
Frequently asked questions
Will all HubSpot integrations stop working on 31 October 2026?
No. HubSpot's notice specifically concerns legacy CRM cards built through the older CRM Extensions API. Modern App Cards and integrations that do not use legacy cards are not automatically affected by this retirement. Audit the actual components before drawing conclusions about the whole integration.
Can a legacy CRM card continue exchanging data after it disappears?
Some background integration processes may continue because the visible card and the wider data integration can be separate components. However, users may lose the information or actions presented through the card. Test the complete workflow rather than treating data sync as proof that the user experience is safe.
Who is responsible for migrating a HubSpot CRM card?
Responsibility normally belongs to the organisation that owns and maintains the app: a software vendor, an internal development team or a CRM development partner. The HubSpot customer should identify the owner, request a dated plan and validate the replacement against its own workflows.
