What to Audit in Your Portal Before You Replace It
A portal audit should take about two weeks and produce six documents. If yours has run longer, the work has probably slid from measurement into redesign. Same thing has happened if the only output was a slide reading "current portal not fit for purpose" with nothing underneath it.
One number reframes the whole exercise. Only 14% of customer service and support issues get fully resolved in self-service, according to a Gartner survey of 5,728 customers. So a weak resolution rate on your Dynamics 365 portal isn't automatic proof the portal failed. Replacement tooling is mature and well documented, so that's not the constraint either. What derails these projects is narrower. The specification handed to the next vendor is a feature list copied off the system being retired. Both problems are fixable without a consultant. Both need you to know where to look before anyone writes the requirements document.
Why is this harder than it sounds? The reason is architectural. Power Pages configuration doesn't live in a repository as files. It lives as records inside Dataverse. Under the standard data model those are adx_ prefixed metadata tables. Under the enhanced model they're virtual tables. Web roles, table permissions, page templates and content snippets are all just rows. There's no committed history to read, and no obvious way to see who changed what.
The usual workaround is a configuration migration, through solutions, the Power Platform CLI, or a records mover utility. Every one of those tools solves the same problem: moving rows between environments. None of them tells you whether anything still depends on the rows being moved. That's the gap where portal replacements stall, and closing it is what the audit is for.
Portal Audit: Key Stats at a Glance
Stat | What it tells you |
14% of service issues | Are fully resolved in self-service, per Gartner's survey of 5,728 customers. Your baseline, before you blame the portal. |
80% of built features | Fail to achieve meaningful adoption, per Pendo's 2024 Global Product Benchmarks. Feature parity is an expensive default. |
6.4% of features | Generate 80% of all user clicks. That ratio is what a usage audit is hunting for. |
74% of organizations | Report IT systems that are overly dependent on one another, per MuleSoft's Connectivity Benchmark Report. Price the integration surface before scoping. |
27% of decision makers | View digital adoption as a critical enabler, though 76% prioritize AI adoption, per Forrester-conducted research. Usage evidence is the step that gets skipped. |
What You Need Before You Start
The audit itself is read-only. It still needs real access, so line these up first.
Power Platform administrator, Dynamics 365 administrator, or System administrator role. Microsoft names these three specifically for site data model operations. Anything less and half the commands return nothing.
Power Platform CLI, version 1.31.6 or higher. Older builds don't carry the site customization report.
A portal contact with a web role holding all website access permissions. You'll need it to load /_services/about on the live site. That's where the portal ID lives.
Ninety days of usage data, minimum. Portal analytics, Dataverse auditing, or web server logs. Thirty days will mislead you if the business has any seasonality.
Your current contract, with the clause defining how users get counted. Not the invoice total. The counting basis.
A non-production copy of the environment. Testing permissions against production with a live customer account is how audits become incidents.
Run pac pages list against the org to confirm you're ready. Your site should appear with its website ID. If it doesn't, your role is wrong, and nothing after this point will work.
Step 1: Inventory the Dataverse Tables Your Portal Actually Reads and Writes
Open every page, list, basic form and advanced form on the site. Write down the Dataverse table and the specific columns behind each one. Page by page. Your output artifact is a table inventory: one row per table, with the columns touched, the direction of travel, and the pages that reference it.
Expect the list to be shorter than the org's table count and longer than anyone's memory of it. Portals collect table permissions for objects that got surfaced once during a pilot and never removed. Those rows are still in live configuration. They still grant access.
Sort the finished inventory by write access. Alphabetical order hides the risk. Read access to a table nobody reads is clutter. Write access to a table nobody watches is a data quality problem running unattended. Copy that permission set across and it comes with you.
Verification is simple. Take any table on your inventory, remove it mentally, then ask which page breaks. If none break, that table isn't part of your portal. It's part of your attack surface.
Step 2: Map Web Roles to Table Permissions, Then Test One Real Account
Configuration says what a user can do. Behavior proves it. This step compares the two, and your output artifact is a permission map with a tested exception list.
Pull every web role and every table permission record. Under the enhanced data model these are component types on the Site Component table. Web role is type 11, table permission is 18, column permission profile is 28. Under the standard data model they're adx_webrole and the associated permission tables. Either way, build the grid: roles down one axis, tables across the other, scope of each grant in the cell.
Now stop reading configuration and go test it. In your non-production copy, sign in as an actual portal contact from each role. Try to reach a record that the role shouldn't see. Try to edit a field that should be read-only.
Which finding matters most? The one where configuration and behavior disagree. A role that looks clean in the grid but returns records it shouldn't is a live problem. It's also worth far more to your business case than any feature gap.
Expert tip: Check whether a portal writes land under the contact's own identity or under a single service account. If every change in the audit history shows the same user, your audit trail is already flattened. No new portal fixes that unless you specify it.
Step 3: Measure What Gets Used, Not What Got Built
Here's where most portal audits quietly stop, and it's the step that changes the budget. Pull ninety days of session data. Rank every page by unique authenticated sessions, then draw a line under the pages carrying the top 80% of traffic. Your output artifact is a ranked usage report.
The shape of that list is predictable. Pendo's 2024 Global Product Benchmarks found 80% of built features fail to achieve meaningful adoption. The same research puts 6.4% of features behind 80% of all user clicks. Portals are no exception. That document library which took nine weeks to build? Usually near the bottom.
This is also the step that gets skipped. Forrester studied 335 director-level and above decision makers in March 2026. Only 27% view digital adoption as a critical enabler, while 76% prioritize AI adoption. Attention flows to the new thing. Measuring the existing thing is unglamorous, and it's where the savings are.
So what do you do with the pages below the line? Deleting them is the wrong reflex. Ask who uses that page, because forty sessions a quarter might be carrying your ten largest accounts. Rank by revenue attached as well as by volume, then cut what survives neither test. If you'd rather walk this with someone, CRMJetty's Dynamics 365 Customer Portal team runs it against your own analytics before scoping anything.
Step 4: Count the Users Your Next Dynamics 365 Customer Portal Contract Will Bill For
Your portal has three user numbers and they're rarely close together. Total contacts with portal login enabled. Contacts who signed in during the last ninety days. Contacts who completed a meaningful action, not a bare login. Your output artifact is those three figures with the gap between them stated plainly.
That gap is money. Power Pages is licensed per authenticated user, and anonymous traffic gets charged per page view. Under that model, every dormant account you carry across bills monthly for nothing. Most estates carry plenty. Deactivating a customer login feels risky, and nobody owns the decision.
So set the deactivation rule now, during the audit, while it's still a data question. Something like: no login in twelve months and no open case moves to inactive, with a reactivation path. Then re-run your count.
Expert tip: Run the same count against the contract clause, not against your assumption of it. Some agreements count every enabled account regardless of activity. Others count peak concurrent sessions. Those two readings of one estate can differ by an order of magnitude, and that difference is the strongest number in your business case.
Step 5: Separate the Customizations That Port From the Ones That Do Not
Every portal has custom work bolted onto it. This step sorts that work into three outcomes: ports as configuration, needs rebuilding, or retires because nothing depends on it any more.
Microsoft's own documentation is unusually direct about what doesn't travel. It names five categories of customization on the adx_ metadata tables that need fixing after a data model migration. Custom columns. Relationships between custom tables and adx tables. Adx references inside Liquid snippets. Adx references inside FetchXML. Custom workflows or plugins registered on adx tables. So if your site has Liquid templates querying adx_webrole directly, that's rework, and you can price it today. Finding it in month three costs considerably more.
You don't have to hunt these down by hand.
Run pac pages migrate-datamodel --webSiteId [your-GUID] --siteCustomizationReportPath [path] and the CLI generates the customization report for you. That report is an audit artifact in its own right, and it's the highest-value command in this entire process.
One constraint surprises people, so flag it early. Four templates can't yet move from the standard data model to the enhanced one. Community, Customer Self Service Portal, Employee Self Service Portal and Partner Portal are all blocked, and Microsoft states this directly. Data model migration is also still a preview feature, which Microsoft says isn't meant for production use. If your Dynamics 365 Portal sits on one of those templates, your options are narrower than a vendor demo will suggest.
Step 6: Turn the Six Artifacts Into a Replacement Spec
You now hold six things. A table inventory, a permission map, a ranked usage report, three user counts, a customization sort, and a list of integration dependencies. The last step turns them into a specification. Write it as: these tables, these roles with these scopes, these pages, this many billable users, this rework, these integrations.
Then read it back against your findings.
Every table listed appears on the Step 1 inventory
Every role scope was tested against a real account, not read from configuration alone
No page made the spec unless it cleared the usage or revenue test in Step 3
The user count uses your next contract's counting basis, after the deactivation rule
Known rework from the customization report is priced, not assumed away
Each integration has a named owner and a stated failure mode
A spec clearing all six lines is also the input to your decision. Three honest conclusions are available, and one of them is to do nothing new.
Fix in place when your findings are mostly configuration defects: over-broad table permissions, unowned integrations, dormant accounts, an unindexed list view. Those defects travel. A new portal inherits every one and adds a migration on top of the bill.
Replace when the constraint is architectural. Three conditions qualify. The data model can't hold what you need. The licensing basis punishes your actual user shape. Or Step 5 rework costs more than a rebuild would.
Split the difference when both are true. Fix now, replace at the next contract break, and use the interval to prove your usage numbers hold.
If the evidence does point to replacement, scope it against the six artifacts and not against a feature list. Talk to the Dynamics 365 Customer Portal team with those in hand, and the conversation starts at requirements.
Common Mistakes to Avoid in a Portal Audit
Auditing features instead of usage. A team walks the portal menu and writes down what exists. That's an inventory of the build, not of the business. You get a parity spec, and it inflates the next project before it starts.
Counting licensed users instead of active ones. The number in the admin center is what you're billed for. It isn't what you serve. Quote the wrong one in a business case and the first vendor who asks about activity will dismantle it.
Treating a slow portal as an architectural verdict. Poor performance usually traces to something small. An unindexed list view. An over-fetching FetchXML query. A page loading a table it never displays. All three are fixes so rule them out before the finding reaches your report.
Testing permissions as an administrator. Administrators bypass the exact restrictions you're trying to verify. Every permission finding has to come from a session as a real portal contact in the role.
Assuming this only applies to Power Pages. Plenty of live estates are still legacy Power Apps Portals or ADXStudio deployments on microsoftcrmportals.com. Every step here works there too, and Step 5 matters more, since the customization debt is older and less documented.
Skipping the integration surface. MuleSoft surveyed 1,050 IT leaders for its Connectivity Benchmark Report. 74% of organizations report IT systems overly dependent on one another. Your Dynamics 365 Portal is rarely the only thing reading those tables.
Letting the audit outrun its own scope. Two weeks, six artifacts. An audit that turns into a redesign never produces the document your budget holder needs, and the decision slips another quarter.
Conclusion
A good audit leaves you holding evidence where you used to hold an opinion. Six artifacts, each able to survive contact with a skeptical finance director. A specification narrow enough that vendors quote against your real usage. That narrowing is the whole return on the two weeks. Teams who skip it aren't choosing badly. They're choosing blind, then paying monthly for the difference.
Whatever your findings point to, the specification is the thing worth protecting. CRMJetty's Dynamics 365 Customer Portal supports real-time two-way Dataverse sync with full CRUD on Dynamics 365 records. Role-based access and a no-code page builder sit on top of that, under user-block licensing with no per-login charge. Original Blog: https://www.crmjetty.com/blog/audit-current-portal-before-you-replace-it/
Comments