Looking after an older Dynamics 365 environment: tips, pitfalls and performance

Many Dynamics 365 environments have been live for years. Some started as on-premises Dynamics CRM, moved to the cloud, and have since been extended by several teams and partners. They still run important work, but each change feels riskier than the last, saves get slower, and nobody is quite sure what every plugin and flow does.

The good news is that most of these environments do not need replacing. They need attention. This article covers the signs, the common pitfalls, how to improve performance, and a routine that keeps things healthy.

Signs your environment needs attention

• Saving a record takes noticeably longer than it used to.
• Users or integrations see throttling errors at busy times.
• Releases are put off because nobody is confident what they will break.
• The same rule seems to be enforced in several places, not always consistently.
• Storage use keeps growing, and nobody is sure why.
• Release wave notices mention features you still rely on being deprecated.

Common pitfalls

Plugin sprawl

Over time, plugins are registered for broad events, such as every update on a busy table, with no filtering attributes. Some are registered twice, some belong to features that were retired, and some call external services synchronously. Each one adds time to every save.

Overlapping automation

Older environments often have classic workflows, Power Automate flows and plugins all reacting to the same change. Classic workflows still run, but Microsoft now directs new automation to Power Automate, and running three mechanisms side by side makes behaviour hard to predict.

Unmanaged changes in production

Quick fixes made directly in production create unmanaged layers on top of your solutions. The next deployment may not change what you expect, because the unmanaged layer wins. It is one of the most common reasons a release appears not to work.

Deprecated features

Microsoft retires features on a published schedule. Older environments often still depend on things such as the deprecated Xrm.Page client API in scripts, the legacy Office 365 (WS-Trust) authentication in integrations, or old plugin and SDK versions. Each one works until the day it does not, so review Microsoft’s deprecation notices with every release wave.

Polling integrations

Integrations that ask Dynamics 365 every few minutes whether anything has changed generate a steady load of requests, most of which find nothing. They are a frequent cause of hitting Dataverse service protection limits.

Storage that keeps growing

Audit history, attachments, email and completed system jobs accumulate quietly. Dataverse storage is licensed by capacity, so unchecked growth becomes a cost as well as a performance issue.

Security that nobody can explain

Security roles copied and adjusted over many years end up with overlapping privileges. People are given extra roles to fix one problem, and the model drifts away from how the organisation actually works.

Finding what is slowing things down

Measure before changing anything. Guessing usually fixes the wrong thing.

• Plug-in trace logs show which plugins run, in what order and for how long.
• Monitor, in Power Apps, shows what happens when a form loads or saves: scripts, plugins and network requests.
• Power Automate run history shows which flows run most often, how long they take and how often they fail.
• Application Insights, connected to the environment through the Power Platform admin centre, gives a longer view of performance and failures over time.
• The Power Platform admin centre shows API usage and storage by table, which points to the integrations and data driving load.

Rank what you find by how much load each item causes and how often users feel it. Then fix in that order.

Improving performance

• Remove what is not needed. Unregister duplicate plugin steps and turn off flows and workflows for retired processes. It is the cheapest improvement available.
• Narrow what remains. Add filtering attributes to update plugins, and use images rather than retrieving the record again.
• Move work out of the save. Logic that does not need to finish before the user carries on should run asynchronously, in an async plugin, a flow or Azure.
• Consolidate automation. Choose one place for each rule. Rebuild classic workflows in Power Automate where it makes sense, and retire the original.
• Replace polling with events. Publish changes from Dataverse to Azure Service Bus or a webhook, so other systems are told when something happens instead of asking constantly.
• Lighten forms. Fewer fields on the first tab, subgrids on tabs that load when opened, and scripts that only run when needed.
• Tidy views and searches. Remove unneeded columns from frequently used views, and keep quick find columns to the ones people actually search on.
• Clean up data. Use bulk deletion jobs for old completed system jobs, set an audit retention period that matches your obligations, and move large attachments to cheaper storage where appropriate.

A routine that keeps it healthy

Every month

• Review failed flows, failed system jobs and plugin errors.
• Check storage by table and API usage for unusual growth.

Every quarter

• Check solution layers on key tables and forms for unmanaged changes.
• Review security role assignments, and remove roles nobody needs.
• Remove or document anything added as a quick fix.

Every release wave

• Read the release plan and deprecation notices for features you use.
• Switch on early access in a sandbox copy of production and test your key processes.
• Update plugins, scripts and integrations that rely on anything being retired.

Tidy or rebuild?

Most older environments are worth tidying. The data model and the processes usually still reflect how the organisation works, and a focused clean-up restores speed and confidence for a fraction of the cost of starting again. A rebuild is worth considering when the data model no longer fits the work at all, when most customisations depend on retired features, or when several environments need to be brought together anyway.

Either way, start with an honest review of what is there. Our health checks do exactly that, and end with a prioritised list of fixes. You can see what this kind of work looks like in our platform performance success story.