CRM Cards vs UI Extensions vs Custom Objects: Choosing the Right Way to Extend HubSpot

If you have been scoping a HubSpot extension project, you have probably hit three terms that sound interchangeable but are not: CRM cards, UI extensions and custom objects. Vendors use them loosely, internal teams use them differently again, and the result is a scoping conversation where nobody is quite sure what they are buying. This guide clears that up.

The short version: these are not three competing ways to do the same job. They sit at different layers of HubSpot. UI extensions are the custom interface layer. Custom objects are the custom data layer. And classic CRM cards are the old way of building custom interfaces, now being retired in favour of UI extensions. Once you see them as layers rather than rivals, the decision becomes straightforward.

The three things, in plain terms

UI extensions (app cards) are how you add custom, interactive interfaces inside a CRM record. Think buttons that trigger an action, live data pulled from an external system, a small workflow your team runs without leaving the contact or deal. They are built with React using HubSpot's component library and deployed through the developer projects framework. HubSpot's user-facing name for a card built this way is an "app card", so you will see both terms used for the same thing.

Custom objects are how you store record types HubSpot does not provide out of the box. HubSpot gives you contacts, companies, deals and tickets as standard. If your business runs on subscriptions, vehicles, properties, shipments or anything else that does not fit those defaults, a custom object models it properly inside the CRM rather than forcing it into a notes field or a spreadsheet bolted on the side.

Classic CRM cards are the legacy way of adding custom cards to a record. They are being deprecated. For any new build the answer is UI extensions, not classic cards, and we will come back to why that matters on a deadline.

Classic CRM cards are on the way out

This is the single most important fact for anyone planning a build. HubSpot has set a sunset date of 31 October 2026, after which classic CRM cards will no longer be supported. The wind-down has already started: from 16 June 2025, no new Marketplace apps containing a classic CRM card are listed or certified, and developers can no longer add new legacy CRM cards to the HubSpot UI.

The replacement is app cards built as UI extensions. HubSpot has also published migration tooling, including a Legacy CRM Card Converter and a view-swap tool that moves legacy cards to app cards while keeping their existing placements. So if you are running classic cards today, you are on a clock, and migration is a known, supported path rather than a rebuild from nothing.

The practical takeaway is simple. If anyone proposes building you a new classic CRM card, that is a red flag. There is no good reason to build on a deprecated technology with a fixed end date. Build on UI extensions instead, and plan any existing classic cards out before the deadline. This is exactly the kind of work our UI extensions service handles, both net-new builds and migrations off legacy cards.

What UI extensions can do that classic cards could not

UI extensions are not just a like-for-like replacement. They are meaningfully more capable, and the biggest difference is where they can live. Classic cards were confined to the record sidebar. UI extensions can be placed in the middle column of CRM record pages (inside default or custom tabs), in the right sidebar, in preview panels across the CRM, and in help desk ticket sidebars. That breadth means you can put the right interface exactly where your team is already working, instead of pushing everything into one crowded sidebar.

There is a tier requirement to be aware of. For private apps (the route most in-house and partner-built extensions take), building UI extensions requires an Enterprise subscription. As of 14 November 2024, all Enterprise-tier customers can build and use private app cards regardless of which Hub they are on, where previously this was limited to Sales Hub Enterprise and Service Hub Enterprise. Worth knowing: while building requires Enterprise, any user in the account can view and use an uploaded extension. You do not need a paid seat just to see it.

When you actually need a custom object

Custom objects answer a different question entirely: not "how do I display this" but "where does this data live". You need one when the thing you are tracking does not fit contacts, companies, deals or tickets, and you want it to behave like a first-class CRM record (with its own properties, associations, list segmentation and reporting) rather than a hack.

Like UI extensions, custom objects are Enterprise only, available across any Hub: Marketing, Sales, Service, Data, Content, Smart CRM and Revenue Hub Enterprise. They are not available on Free, Starter or Professional tiers. You can create them through the UI under Data Management, or through the Custom Objects API. HubSpot limits the number of custom objects per portal and applies record and property ceilings, but the exact figures are governed by HubSpot's product catalogue rather than a fixed published number, so confirm the current limits for your subscription before you design around them.

How they combine in practice

Here is where the "vs" framing falls apart, because the best builds use these together. A very common pattern looks like this: a custom object holds the data, and a UI extension surfaces that data on the associated contact, company or deal record and lets your team act on it without leaving the record.

Imagine you sell equipment on service contracts. The contracts live in a custom object. A UI extension on the company record shows the active contracts, their renewal dates and a button to raise a renewal task. The data model and the interface are doing separate jobs, and together they give your team something HubSpot does not offer as standard. This is the legitimate, supported version of what teams used to cobble together with classic cards and brittle middleware, and it is far more robust.

So the decision tree is genuinely short. Need to store data HubSpot does not model? That is a custom object. Need a richer or interactive interface on a record? That is a UI extension. Need both, which is often the case? Build them to work together. And whatever you do, do not build on classic CRM cards for anything new.

A clean way to decide

Most teams overthink this because the vocabulary is muddled, not because the choices are hard. Get the data model right first (custom objects if your records do not fit the defaults), then decide how people interact with it (UI extensions for any custom interface), and treat classic cards purely as something to migrate away from before October 2026.

If you would rather not work this out alone, that is what we are here for. SpotDev is a UK HubSpot Diamond Partner and a software engineering firm built around HubSpot customers, with HubSpot Custom Integration Accreditation and an in-house engineering team. We scope these builds properly, recommend the simplest thing that works, and we will tell you when you do not need a custom build at all. UI extensions start from £8,000. You can see the full range on our HubSpot development hub, and if you are weighing up the wider picture, our guides on what you can build with custom HubSpot development and how much a HubSpot developer costs in the UK are good next reads.

If you already know roughly what you want, the fastest route is to request a quote and we will come back with a scoped recommendation, delivered on time or you get 20% back.

Frequently asked questions

Are CRM cards the same as UI extensions?

No. Classic CRM cards are the legacy way of adding custom cards to a HubSpot record, and they are being deprecated with a sunset date of 31 October 2026. UI extensions (also called app cards) are the modern replacement, built with React. For any new build you should use UI extensions, not classic CRM cards.

Do I need a custom object or a UI extension?

They solve different problems. A custom object is for storing data HubSpot does not model out of the box, such as subscriptions, vehicles or shipments. A UI extension is for adding a custom, interactive interface to a record. Many builds use both: the custom object holds the data and a UI extension surfaces and acts on it inside the record.

What tier of HubSpot do I need for UI extensions and custom objects?

Both require an Enterprise subscription. For private app UI extensions, all Enterprise-tier customers can build and use them across any Hub as of 14 November 2024. Custom objects are also Enterprise only and available across Marketing, Sales, Service, Data, Content, Smart CRM and Revenue Hub Enterprise. Neither is available on Free, Starter or Professional.

What happens to my existing classic CRM cards after October 2026?

Classic CRM cards will no longer be supported after 31 October 2026. HubSpot has published migration tooling, including a converter and a view-swap tool that moves legacy cards to app cards while preserving their placements, so existing cards can be migrated to UI extensions rather than rebuilt from scratch. We recommend planning this work well before the deadline.

How many custom objects can I create in HubSpot?

HubSpot limits the number of custom objects per portal and applies record and property ceilings, but the exact figures are set by HubSpot's product catalogue rather than a single fixed published number. Confirm the current limits for your specific subscription before you design your data model around them.