A buyer logs into your B2B portal to reorder 400 units of a SKU they've bought six times before. The price shown doesn't match their negotiated contract rate. The inventory says, "in stock," but the warehouse system says otherwise. They abandon the cart, call their sales rep, and place the order over email instead.
This isn't a UX problem. It's a systems problem. And it's happening inside portals that were architected a decade ago, bolted onto ERPs through middleware that nobody on the current team fully understands anymore.
The question procurement and IT leaders are now asking isn't "should we redesign the portal." It's whether Dynamics 365 Commerce can replace the portal entirely, and whether that replacement is worth the disruption.
Where Legacy B2B Portals Actually Fail
Most legacy portals were built as a presentation layer sitting on top of the ERP, connected through nightly batch syncs or custom API middleware. That architecture made sense when B2B buyers tolerated 24-hour price updates and manual quote approvals. It doesn't hold up against buyers who expect the same real-time accuracy they get from consumer platforms.
Three failure points show up repeatedly in portal audits:
Pricing drift. Contract pricing, volume discounts, and reseller terms live in the ERP. When the portal maintains its own pricing logic, or syncs on a delay, buyers see stale numbers. Finance then spends hours reconciling invoiced amounts against what the portal displayed.
Inventory disconnect. Cross-channel inventory visibility, stock committed to other outlets, in-transit quantities, safety stock thresholds, rarely makes it into legacy portals cleanly. The portal shows a static snapshot instead of a live position.
Fragmented order orchestration. A single B2B order might need to route across multiple warehouses, apply different fulfillment rules per outlet, and trigger credit checks before it's confirmed. Legacy portals usually handle this through custom scripts stitched together over years, which makes every ERP upgrade a risk to test around.
None of these are visible to the buyer as "the portal is broken." They register as friction, and B2B buyers with alternative suppliers don't tolerate friction for long.
What Dynamics 365 Commerce Actually Changes
Dynamics 365 Commerce isn't a portal bolted onto Finance and Operations. It's built on the same headless commerce engine that runs the ERP's retail and wholesale scenarios, which means pricing, inventory, and order logic aren't duplicated in a separate system, they're read directly from the source of truth.
A few capabilities matter specifically for B2B buyers moving off legacy portals:
Multi-outlet ordering with outlet-specific catalogs. Buyers purchasing across multiple business units or franchise locations can place orders against catalogs scoped to their specific outlet, with pricing and product availability that reflects that outlet's actual terms, rather than a generic B2B price list applied uniformly.
Built-in credit management. Credit limits, holds, and exposure checks run inline during checkout instead of as a post-order manual review. This closes a gap that forces many legacy portals to route large orders to a sales rep for manual credit sign-off, adding days to the cycle.
Unified sign-in across channels. A buyer's identity, order history, and negotiated terms carry across web, call center, and assisted-selling interactions. A rep taking a phone order sees the exact same pricing and stock position the buyer sees online, which eliminates the "the portal says one thing, the rep says another" complaint that shows up constantly in B2B satisfaction surveys.
Order orchestration tied to real fulfillment logic. Orders route based on live inventory position and outlet rules, not a static warehouse assignment configured once and never revisited.
For a distributor running fragmented pricing logic across a custom portal and three regional ERPs, this consolidation alone can eliminate the reconciliation work that currently ties up a finance analyst for a week every month-end.
The Migration Reality Nobody Puts in the Pitch Deck
Replacing a legacy portal with Dynamics 365 Commerce is not a lift-and-shift. It's a re-architecture, and the honest version of that conversation includes what doesn't move over cleanly.
Custom workflows built into legacy portals, approval chains specific to one client's procurement process, bespoke quote-to-order logic, or integrations with a niche logistics provider, don't have a direct equivalent inside Commerce out of the box. Some of this maps to configuration. Some requires extension development on top of the platform. Teams that assume Commerce is a drop-in replacement usually discover this three weeks into discovery, not before the project starts.
Data residency and identity also need early decisions. Buyer authentication typically routes through Microsoft Entra External ID or a comparable identity provider, and if the legacy portal handled authentication through a custom SSO setup tied to a client's own identity system, that mapping has to be solved before go-live, not treated as a cutover-week task.
The realistic sequence looks like this: audit the current portal's business logic and separate "ERP should own this" from "portal-specific customization that needs to be rebuilt," map outlet and pricing structures into Commerce's data model, pilot with a single outlet or customer segment, then expand. Firms that skip the audit and migrate all customers in one cutover are the ones that end up running both systems in parallel for six months longer than planned.
When the Replacement Makes Sense, and When It Doesn't
Dynamics 365 Commerce is the stronger fit for organizations already running Dynamics 365 Finance and Operations, where the legacy portal's core problem is pricing and inventory drift against that same ERP. The consolidation gain is direct and measurable.
It's a weaker fit for mid-market wholesalers on Business Central rather than Finance and Operations, since Commerce is architected around F&O and retail scenarios. In that case, a Dynamics-native B2B commerce layer built specifically for Business Central usually solves the same pricing and inventory problems with less architectural mismatch.
The decision isn't "modernize the portal" versus "replace the portal." It's whether the buyer-facing friction you're losing deals to traces back to the ERP connection itself. If it does, Commerce addresses the actual cause. If the friction is closer to workflow customization that a generic B2B commerce platform can't replicate, the fix looks different, and no platform migration solves a problem that was never architectural to begin with.
Where to start: run a portal audit that separates ERP-sourced data problems from portal-specific customization before scoping a migration. That distinction determines almost everything about cost, timeline, and whether Dynamics 365 Commerce is the right answer at all.
If you're weighing this decision for your own B2B operation, Dynamics Monk runs exactly this kind of audit before recommending a migration path. Book a discovery call to see where your current portal's friction actually originates.
Originally published on the Dynamics Monk blog.
