SSO and ERP Integration: How Customer Portals Connect to Legacy Systems

"Our ERP can't do that." More customer portal projects die on this sentence from the IT department than on any budget veto. But it rests on a false assumption: that the legacy system has to do the integration work. It doesn't. Connecting the systems is the portal's job — more precisely, the job of an integration layer that sits between the portal and your existing systems. What your ERP actually needs to bring to the table is surprisingly little.

This article answers the two technical questions every customer portal project should settle before the first line of code: How do users get in securely — meaning identity, SSO, and roles for customer organizations? And how does data get out securely — meaning the connection to ERP and CRM? Both are solved problems if you pick the right patterns. And both determine whether the portal actually replaces support requests or merely relocates them.

A customer portal without a connection to your systems of record is a brochure with a login. Customers sign in, see static content — and then call anyway, because the order status isn't there. This is exactly where self-service fails in practice: according to Gartner (2019), 70 percent of customers use a self-service channel at some point on their way to a resolution, but only 9 percent resolve their issue completely without live contact. The gap between those two numbers is rarely a frontend problem. It's the data behind it: order status, invoices, and delivery dates live in the ERP — and if the portal doesn't show them up to date, it just pushes the phone call back by ten minutes.

The MuleSoft Connectivity Benchmark 2025 confirms that integration is the real construction site: companies run an average of 897 applications, but only 29 percent of them are integrated with each other — and only 2 percent of organizations have more than half of their systems connected. A customer portal that simply gets parked next to the rest as application number 898 makes this problem worse. Scoped correctly, however, it becomes the first layer that makes your existing data consumable at all — first for customers, later for other systems too.

Before any data flows, the portal needs a solid answer to the question of who is actually accessing it. In B2B, this is more complicated than in consumer business: your customer isn't a person, it's an organization. The buyer is allowed to place orders, the service technician only sees maintenance contracts, accounting only sees invoices — and when someone leaves the company, their access has to be revoked centrally, not in five systems one by one.

We solve this with Keycloak, an open-source identity server that we self-host in the EU. That's not an exotic choice: Keycloak has been an incubating project of the Cloud Native Computing Foundation since April 2023 and has been running in production for over eight years at organizations like Accenture, CERN, Cisco, and Hitachi. Documented references include FAPI-compliant API authorization for Japanese banks and the migration of Austria's business service portal with more than two million users — exactly the "external portal with many organizations" scale we're talking about here. We've covered what Keycloak does in detail in our Keycloak guide.

The identity layer handles three jobs in the portal: First, company accounts with multiple users and a role model per customer organization. Second, single sign-on — one login for the portal and neighboring systems, optionally federated with your customer's directory service (such as Entra ID), so their employees sign in with the company credentials they already use. Third, tenant isolation in the database: in our stack, Supabase Row Level Security enforces that customer A can never, under any circumstances, see customer B's data — at the database level, not just in application code. Why we use exactly this combination and what it costs to operate is covered in our field report on the Supabase-Keycloak stack.

One detail that gets underestimated in B2B projects again and again: identity has to be tied to the ERP's master data. Your customers know their customer number, not their portal user ID. If you model the mapping between portal accounts and ERP customer and contact numbers cleanly during onboarding, you save yourself a mountain of manual activation tickets later — and you lay the groundwork for deriving roles and approval levels from the system of record instead of maintaining them twice.

There is no one-size-fits-all solution for the data flow between portal and legacy system — there are four basic patterns. Which one carries the load depends less on the portal than on two questions: What can your ERP deliver today — and how fresh does the data really need to be from the customer's point of view? A delivery date has to be correct the moment the customer looks it up. Last week's invoice can come from a nightly sync.

In practice, we almost always combine patterns: master data and invoices are synchronized, order status comes in live or via events, and everything runs through an integration layer that presents the portal with a single unified API. The portal then doesn't even know whether a piece of information comes from SAP, proALPHA, or a file share — and that's precisely the point: if you switch ERPs in five years, you swap out an adapter, not the portal.

A word on data sovereignty: synchronization creates a copy of customer data in the portal database. Under GDPR, that's unproblematic if three things are in place — EU hosting for the portal infrastructure, data minimization (replicate only the fields the portal displays), and a defined deletion path when a customer leaves. All three belong in the discovery phase, not in an addendum to the data processing agreement.

The most common planning mistake is building the integration in both directions at once. Read access — the customer sees orders, invoices, delivery status — is low-risk: worst case, the portal shows slightly stale data. Write access — the customer triggers an order or an address change that lands in the ERP — touches business logic, validations, and, if things go wrong, your accounting.

That's why we build portals read-first: the first release shows existing data and already eliminates the most common calls ("Where's my order?", "Can you resend that invoice?"). Write operations follow as a second stage — and then not as a direct passthrough into the ERP, but as defined jobs sent to the integration layer, which validates, logs, and reports back cleanly to the customer if something fails. This dramatically reduces project risk and delivers measurable value within a few weeks, instead of a big-bang release many months later that gets judged by its first failed posting.

The checklist is shorter than most IT leaders expect. Minimum: a way to get data out — an API, database access, or, if all else fails, a regular export. That's enough for synchronization and thus for a fully functional read-only portal. Better: a documented interface or event capability; then live data and, later, write operations are cleanly achievable. Not required: a "web-ready" ERP, a version upgrade before the project starts, or — worst of all — an ERP replacement. This also applies to the typical mid-market systems beyond SAP — whether proALPHA, abas, or a Dynamics installation that has grown over the years: what matters is data access, not the age of the user interface.

This explicitly includes systems that are already internal modernization candidates. A portal as a modern layer in front of a legacy ERP is often the most pragmatic first modernization step: customers get contemporary self-service while the core system keeps running untouched — and the integration layer built along the way later carries the step-by-step replacement of the legacy system. The reverse is also true: if your actual problem is the state of the core system and the portal would just be treating symptoms, we'll tell you so in the first conversation — then modernization is the project, not the portal.

For context, our published price anchors: a customer portal with a roles-and-permissions model and a first ERP integration runs 20,000 to 60,000 euros with us. The range depends mainly on two factors: how many systems get connected and whether the ERP brings a usable interface or the integration layer has to do more translation work. A portal MVP with Keycloak login and a first self-service feature runs 8,000 to 20,000 euros — often the right way to prove the integration on a real use case before committing to the larger investment.

As of July 2026. All prices net of VAT. The ranges above are our published price anchors; all market figures in the text are attributed with source and year.

If a customer portal is on your roadmap, settle the integration question before selecting a vendor — with three answers: Which data do your customers need most urgently? Where does it live? And what can the system of record deliver today? These three answers determine pattern, effort, and timeline more reliably than any feature list. How we build customer portals — including our price table and make-or-buy framework — is documented in the open. Or we can walk through your system landscape together: in a free 30-minute intro call, ideally with your IT team at the table.