Auditing a Failing Client Portal Before Your Renewal Is at Risk

If your third-party customer portal barely integrates with Dynamics 365 and major customers are threatening to leave, do not decide between fixing and replacing it until a short assessment has answered four questions. What does the integration do today, and where does it fail silently? Can the data model underneath support the experience customers expect? What do performance and security testing find? How much of the promised functionality was ever delivered? The answers point to one of three routes: harden the existing portal when its integration and data model are sound, rebuild on Power Pages when screens are mostly forms and case views over Dataverse, or build a custom front end against Dataverse when the experience is the product.

This is a decision guide for the week the board starts asking questions. It covers what to do immediately, the assessment, and the conditions under which each route is right. The detailed comparison of Power Pages against a custom front end, including licensing as the audience grows, identity, data residency and maintenance, already exists in our guide to choosing Power Pages or a custom front end for a customer portal, so this post defers to it rather than repeating it.

What should you do first while customers are threatening to leave?

Stabilise the relationships before you touch the technology, because a replacement will not arrive in time to save an account that leaves next month.

1. Talk to each customer at risk and write down exactly what fails for them: the screen, the action, the data that is wrong or missing, and how often. Vague frustration cannot be fixed; a list can.
2. Give those customers a named contact and a manual fallback for the failures that hurt most, such as a service desk that can update a case or send a document the portal should have shown.
3. Stop promising dates for fixes nobody has diagnosed.
4. Send a short, honest status update: what you have found, what you are doing about it and when you will next report.
5. Freeze non-essential changes to the portal and the integration, so the assessment is not measuring a moving target.

Contract, commercial and renewal terms with your customers or with the portal vendor are for your own leadership and legal advisers. What follows is the technical evidence they will need.

What does the integration actually do today, and where does it fail silently?

Map it from evidence rather than from the vendor documentation. For each thing a customer does in the portal, such as viewing a case, submitting a request, downloading an invoice copy or updating contact details, trace where the data comes from and where it goes:

• Direction and timing: is the portal reading Dataverse live, reading its own copy synchronised on a schedule, or writing to its own database and pushing changes later?
• Identity and scope: how does the portal decide which account's data a user may see, and does that logic live in the portal, the integration or Dataverse?
• Failure handling: when a call to Dynamics 365 fails or is throttled, does anything retry, log the failure or alert anyone, or does the customer simply see stale data or a request that never arrives?
• Reconciliation: pick a recent period and compare records on both sides, such as cases created, statuses and documents. Every record that exists on one side only is a silent failure.
• Credentials and ownership: which account the integration runs under, who owns it, and whether it is tied to a person who has left.

Silent failure is the finding that matters most. A portal that errors loudly is annoying; one that accepts a customer request and never delivers it to Dynamics 365 is why customers stop trusting it. Dataverse API limits and throttling are a common hidden cause; our guide to protecting interactive users from Dataverse API limits covers how that shows up.

Can the data model underneath support the experience customers expect?

Often this decides the whole question. A portal cannot show customers something Dynamics 365 does not hold, or holds in a shape that makes it impossible to query.

Check whether the records customers need are actually in Dataverse or in another system, whether they are linked to the right account and contact so access can be scoped correctly, whether statuses mean something a customer would understand, and whether the history customers ask for, such as previous service visits or older documents, exists at all. Where the answer is no, no portal technology will fix it, and replacing the front end first will reproduce the same complaints on a newer screen. The model has to be fixed first; our guide to Dataverse data model remediation covers that work.

What do performance and security findings usually decide?

Performance findings tell you whether the problem is the portal or what sits behind it. Measure page load and action times for real customer accounts, including the largest ones, since large accounts with many records are usually the ones complaining. If the slow part is the call to Dynamics 365, a new front end over the same queries will be just as slow.

Security findings can make the decision for you. Test whether a signed-in user can reach another customer's records by changing an identifier, whether the integration account has far more privilege than it needs, whether credentials are stored or shared unsafely, and whether access is removed when a customer contact leaves. A portal that exposes one customer's data to another needs containment before any fix-or-replace decision. If the replacement is on Power Pages, our guides to Power Pages table permissions and data leaks and Power Pages portal performance cover the equivalent risks on that platform.

How much of the promised functionality was ever delivered?

Build a contracted versus delivered map. List every capability the portal was sold on, from the proposal, statement of work and change requests, and mark each one as delivered and working, delivered but failing, partly delivered, or never delivered, with the evidence for each. This turns a general sense that the portal "never worked" into a specific list, and it separates defects from features that were never built from features that were never actually agreed.

The map also changes the decision. A portal that delivered most of its scope with fixable defects is a hardening job. A portal where the core capabilities customers need were never delivered is usually a replacement, whatever the sunk cost.

Our Dynamics 365 health check and technical audit is the fixed-scope vehicle for this assessment on the Dynamics 365 and Dataverse side, including the integration, the data model, security and a contracted versus delivered map, with evidence your board, the vendor or another supplier can reproduce. It is a technical assessment, not a legal opinion on the vendor contract.

When is hardening the existing portal the right call?

When the assessment shows the foundations are sound and the failures are specific:

• The integration reads and writes the right data, and its failures are fixable, such as missing retries, missing alerting or an expired credential.
• The data model already holds what customers need, correctly linked for access scoping.
• No fundamental security flaw is built into the design.
• Most of the promised functionality was delivered, and the vendor or your own team can still change the code.
• Customers mainly need reliability, not a different experience.

Hardening usually means adding error handling, retries and alerting to the integration, a daily reconciliation report, tightened integration permissions, performance fixes behind the slowest screens and a named owner. It is the fastest route to rebuilding trust, and it can buy time even when a replacement follows later.

When is rebuilding on Power Pages the right call?

When the portal is mostly forms, lists, case status and document upload over Dataverse, the audience is large or grows by sign-up, and your team already maintains Power Platform. Power Pages reads Dataverse directly, which removes the synchronisation layer that often causes silent failures, and it has table permissions and web roles for scoping each customer to their own records. It is also a strong route when the existing vendor can no longer support the portal.

How Power Pages is licensed as the audience grows, and how its identity and access review work, are covered in the portal route comparison. What a Power Pages build involves is set out on our Power Platform consulting service. Check current Microsoft licensing terms before you budget, because they change.

When is a custom front end against Dataverse the right call?

When the experience itself is what customers are buying, performance targets are strict, identity or workflow is unusual, and you can fund engineers to own the front end for its whole life. A custom React or Next.js front end calling the Dataverse Web API gives complete control of the experience, but it is not a way around Microsoft licensing when the data stays in Dataverse, and it moves security scoping into your own code, which then has to be tested as rigorously as any product.

If the assessment shows the deeper issue is that the Microsoft platform no longer fits, for example many external users, hosting rules or a process no packaged platform expresses well, a custom-built CRM with its own database and portal is the route that avoids Microsoft licensing. That is a larger decision than replacing a portal, and it should be made on requirements rather than frustration.

How do you replace a portal without a second outage for customers?

In stages, with the old portal still available until the new one is proven for each group of customers:

1. Fix the data model and integration gaps the assessment found, because every route depends on them.
2. Build the capabilities customers use most first, not the whole original scope.
3. Pilot with a small number of friendly accounts, then with the accounts at risk, whose named contacts can see their specific complaints resolved.
4. Reconcile data between old and new portals during the overlap, so nothing a customer submits is lost.
5. Move remaining customers in waves, with a rollback position for each wave.
6. Retire the old portal and its integration account only when every wave is complete.

How does Solzet help with a failing customer portal?

We run the assessment first: the integration, the Dataverse data model, performance, security and a contracted versus delivered map, as a fixed-scope health check with a report you can act on with any supplier. If the evidence supports hardening, we can stabilise the integration. If it supports replacement, we build on Power Pages, as a custom front end against Dataverse, or as a custom-built CRM where Microsoft licensing does not fit, and we recommend on the findings rather than on what we would prefer to build. We do not advise on customer or vendor contracts. Our senior consultants and full-stack developers bring 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, working remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.