Salesforce B2B Replacement

to Azure

Piece 1: Build a B2B portal with sign-on landing page with multi-tenant. Build your portal UI screens in React to ensure sub-second page loads over complex B2B workflows like bulk ordering or custom quoting. Build a portal interface that lets your customers' admins invite, deactivate, and assign roles to their own team members without opening support tickets.  Launch the new portal initially as a fast, read-only hub for order history, invoices, and account details fed by your synced DB and a read-only dashboard with totals.

Piece 2: Build a dedicated .NET API layer that sits between your new portal UI and Salesforce. The Backend-for-Frontend pattern aggregates data, handles caching, and abstracts Salesforce's proprietary API limits from the frontend. Use Salesforce's OpenAPI 3.0 Generator requesting only the specific SObjects (e.g., Account, Contact, Custom_Order__c) and endpoints you actually use resulting in OpenAPI YAML/JSON. Feed the extracted OpenAPI YAML/JSON into a tool like openapi-generator-cli or swagger-codegen to instantly scaffold your server routes, controllers, and DTOs. However, you must verify that you keep the exact 1) property casing that SalesForce uses and 2) proprietary formats, such as returning { "id": "...", "success": true, "errors": [] } on record creation and { "totalSize": 1, "done": true, "records": [...] } on queries.  Use Salesforce Change Data Capture or Platform Events to stream changes into your DB. (Do not query Salesforce synchronously on every page load, otherwise you will hit API rate limits.)

Piece 3: Migrate user authentication off Salesforce Experience Cloud onto a dedicated IdP like Microsoft Entra External ID using the deployment model of "External" tenant configuration (for B2Bs). (This eliminates recurring Salesforce external user license fees.)  Map users to specific B2B accounts (organization_id) and inject custom roles (e.g., Buyer, AccountAdmin, BillingViewer) as claims into their OAuth/JWT tokens. 

Piece 4: Create your DB. 

Piece 5: Create API data layer that maps parameters to your fields on your screens and your DB using EF.

Phase 1: Launch the new B2B portal initially as a fast, read-only hub for order history, invoices, and account details fed by your synced DB and a read-only dashboard with totals.

Phase 2: Use "Strangler Fig" migration strategy. You have 4 options: 1) doing the high-value or high-friction workflows next (such as custom pricing calculators, self-service renewals, and support ticket creation), 2) doing all parts of a particular Salesforce module, 3) doing common workflows to reduce the number of users since Salesforce charges per user 4) or doing all parts of a particular Salesforce cloud (such as Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, and Data Cloud) since they are licensed individually. Gradually move workflows into the new portal writing data back to Salesforce via asynchronous queues.

Phase 3: Decommission each Salesforce module/cloud after you fully remap it. Once a workflow is fully operational and adopted in the new portal, turn off the corresponding Salesforce Experience Cloud pages and drop the unused external licenses.