Signs You Have Outgrown Your Off-the-Shelf Customer Portal (and What to Do)

Most customer portals start as a sensible decision. You bought an off-the-shelf product, stood up a Salesforce or Dynamics community, or commissioned a quick bespoke build. It cleared a backlog of customer questions and looked fine for a year or two. Then the business grew, the use cases multiplied, and the portal quietly stopped keeping up. The failure is rarely dramatic; it is a slow accumulation of workarounds, where your team fills the gaps the portal cannot, customers drift back to email and phone, and the tool you bought to cut manual work becomes another system to maintain.

This post is about recognising that point and deciding what to do. If you are still weighing options from scratch, start with the pillar on customer portals for mid-market B2B; this piece assumes you have something live that is hitting its limits.

Five signs you have outgrown your portal

Any one of these on its own is survivable. Two or three together usually means the platform, not the configuration, is the constraint.

1. You cannot surface the data you actually need

The portal shows what the vendor decided portals should show: tickets, orders, a knowledge base. But your customers want their live project status, the documents tied to their account, renewal dates, usage against an agreement, or a field your team added to the CRM last quarter. If a new data point means a feature request to a vendor or a quarter of internal backlog, the portal is dictating what your business can offer.

2. You cannot enforce your own rules and permissions

Mid-market B2B relationships are rarely flat. One company has three contacts who should see invoices and two who should not; a partner sees their own accounts but never a competitor's; a member sees content gated by their tier. Off-the-shelf portals tend to offer a fixed permission model, and when your real-world rules do not fit it, the gaps get filled by people, or you do not expose the data at all because you cannot control who sees it safely.

3. Per-seat costs are climbing faster than the value

Per-user and per-login pricing is fine at fifty users. At a few hundred it becomes a line item someone questions every renewal, and the model starts shaping behaviour: you ration logins, share accounts (a security problem), or hold a rollout back from a segment that would benefit because the seat maths does not work. When the commercial model is constraining adoption, you have outgrown it.

4. The team still fills the gaps by hand

This is the clearest signal. The whole point of a portal is that customers serve themselves and your team stops doing the system job: chasing updates, re-sending documents, answering "where are we up to" by hand. If your people are still copying data out of the CRM into the portal, emailing exported reports, or re-keying the same status into two places, the portal is not removing the manual work; it is adding a place to maintain it. We cover this pattern in stop chasing customers for documents and status.

5. It will not integrate with the rest of your stack

A portal is only as good as the data flowing into it. If it cannot connect cleanly to your CRM, finance system, project tooling or operational database, you end up with batch exports and overnight syncs that drift, or a portal showing data that is a week stale. Customers notice the moment the portal disagrees with what your team told them on a call. For most mid-market businesses the CRM should be the single source of truth and the portal a window onto it; if your portal cannot treat it that way, that is a structural limit. Our integrations work and the guide to connecting your stack show what real-time data flow looks like.

Extend what you have, or replatform?

Recognising the symptoms is the easy part. The real decision is whether to extend your current portal or replace it. Spend in the wrong direction and you either pour budget into a platform that hits the same wall next year, or replatform something that just needed a tidy-up.

When extending is the right call

• The limits are configuration, not architecture: the data and permissions you need are technically supported, but nobody has set them up.
• The integration you are missing is available and reliable, just not switched on.
• Costs are manageable and adoption is healthy; one or two journeys are clunky, but the core model fits how your business actually works.

If that is you, fix the configuration, connect the data properly, and move on; a focused engagement on your CRM and data layer often does more than a new portal would. Our work on CRM implementation and data engineering is often the cheaper, faster answer.

When replatforming is the right call

• The data or permission model you need is not supported and never will be, because the vendor's product is not built for it.
• Per-seat economics make full rollout uneconomic, or the portal cannot integrate with your stack in real time, so it will always show stale or partial data.
• Your team's manual gap-filling has become a permanent job, and you are paying for a platform but still cannot do the three things your customers most want to do themselves.

The honest test: if you mapped the three journeys your customers most need and your current portal cannot run any of them properly, you have outgrown it, and extending will not change that. This is the decision the build vs buy guide for customer portals is built to walk you through, trade-offs laid out side by side.

The replatforming path: how a clean replacement actually works

The fear that stops most teams replatforming is the migration: a multi-month project, a risky data move, a window where customers lose access. It does not have to be. A custom portal built on proven foundations avoids the blank-page problem. Rather than designing from scratch, you choose proven journeys (typically three), adapted to your brand, systems, data, fields, permissions, notifications and integrations. That is productised scope on a custom build, not a generic template, which is why a SpotDev portal is fixed-price from £15,000 and launched in 30 days from contract signing, with working software to look at within about two weeks. That speed depends on a fixed scope, fast access to the systems you connect, and prompt feedback; it is not magic, but an experienced in-house engineering team reusing what already works, so the time goes into your rules and your data.

The data move, without losing access

Moving customer records, history and documents off the old platform is a data migration exercise, one of the better-understood problems in this space: map the old data model to the new one, clean what is worth keeping, and load it so the new portal opens with correct records. A fixed-price, fixed-timeline launch assumes a reasonable data move, not an open-ended data-cleansing project, a complex legacy-system rebuild, or unlimited integrations; if your old data is a mess, that cleanup is a separate piece to scope honestly up front.

You do not have to flip a switch overnight, either. A sensible replatform runs the new portal alongside the old one for a short period: a pilot group moves first, you confirm the data and permissions behave, then you migrate the rest and retire the legacy portal. Because the new build is ready for real users by day 30, that parallel-running window is short. If your current portal is a community on a CRM you are also outgrowing, the move can pair with a wider one; our managed RevOps work covers keeping operations running through it. SpotDev has built customer portals for Superior, Wolsey Hall Oxford, Icon Solutions and L&DI, so the path is well-worn rather than experimental.

What to do next

Be honest about which of the five signs apply, and whether they are configuration or architecture problems. Configuration problems you fix in place; architecture problems no amount of extending will solve. Not sure which? Our diagnostics are built for that triage. Once you have decided to replace, take the decision properly with the build vs buy guide, then see what a productised, fixed-price replacement looks like on the customer portals page. The shortest route to a portal that fits is usually not another off-the-shelf product.

Frequently asked questions

How do I know if I should extend my current portal or replace it?

If the limits are configuration, the data and permissions you need are technically supported but not set up, extending is usually right. If the limits are architectural, the platform cannot surface your data, enforce your rules, integrate in real time, or scale economically, then extending only delays the same problem. A quick test: map the three journeys your customers most need; if your current portal cannot run them properly, you have outgrown it.

Is migrating off an existing portal risky?

It is a well-understood data migration exercise, not a leap into the unknown. The work is to map the old data model to the new one, clean what is worth keeping, and load it so the new portal opens with correct records. Running the new portal in parallel with the old one for a short pilot, then retiring the legacy system, keeps customers from losing access or history during the switch.

How long does it take to replace a portal we already have?

A SpotDev portal is launched in 30 days from contract signing, with working software to review within about two weeks. That timeline depends on a fixed scope, fast access to the systems being connected, and prompt feedback. A straightforward data move fits inside that; an open-ended data-cleansing project or a complex legacy-system rebuild would be scoped separately.

Why are per-seat portal costs a problem at our size?

Per-user pricing is fine at fifty users and starts to bite at a few hundred. It tends to shape behaviour in unhelpful ways: rationing logins, sharing accounts, or holding back a rollout that would benefit a customer segment because the seat maths does not add up. When the commercial model is constraining adoption rather than the product itself, that is a sign you have outgrown the platform.

What does a replacement portal cost?

A SpotDev customer portal is fixed-price from £15,000, with £5,000 due on contract signing and the balance before launch; hosting is a recurring charge. Additional journeys beyond the proven set are £2,000 each. Open-ended product development, complex legacy rebuilds, bespoke mobile-app functionality, data-cleansing projects and unlimited integrations sit outside that fixed price. For a full decision framework, see the build vs buy guide.