Many Dynamics 365 projects assume performance will “just work” because the platform runs in the cloud.

That assumption is responsible for a surprising number of go-live issues.

Microsoft’s Success by Design framework repeatedly highlights that performance problems are rarely infrastructure issues — they are usually solution design problems.

And the uncomfortable truth is this:

Performance is engineered during implementation — not after go-live.

If performance is not considered early, the project will eventually pay the price.

Dynamics 365 runs on Azure, which provides highly scalable infrastructure.

But solution performance still depends on how the implementation is designed.

In the cloud world, adding hardware is rarely the answer.

Instead, performance depends on things like:

The Success by Design guidance stresses that architecture decisions directly affect scalability and reliability of the solution.

A poorly designed solution can easily overwhelm a perfectly healthy cloud platform.

One of the most important concepts emphasized by Microsoft is that performance is not owned by one party.

It is shared between three stakeholders.

The customer understands the business workload:

They must also allocate time and resources for performance testing.

The partner is responsible for the solution architecture:

Microsoft provides the platform foundation:

But Microsoft cannot fix poor design decisions in a project.

One of the recurring lessons in Dynamics 365 projects is this:

Performance testing often starts too late.

It is sometimes treated as a final step before go-live — when major architectural changes are already impossible.

Microsoft recommends integrating performance testing into the overall testing strategy and project plan from the beginning.

Key recommendations include:

In practice, performance testing should begin well before UAT.

A common mistake in performance testing is trying to test everything.

Instead, teams should focus on critical business scenarios that represent real workloads.

Examples in Finance & Operations projects include:

Performance testing should simulate real operational conditions, including concurrency and peak loads.

Performance goals should be defined as non-functional requirements (NFRs).

These should be agreed with the business and documented early in the project.

Typical examples include:

For example:

Microsoft recommends formal sign-off of these goals by stakeholders so they become measurable acceptance criteria later in testing.

Performance testing only works if the environment and data are realistic.

Microsoft highlights several prerequisites.

Testing must reflect production volumes, including peak loads.

Latency between users and Azure regions must be validated.

Different users generate different workloads.

Testing should simulate realistic personas such as:

Performance testing should run in an environment similar to production.

Testing in shared development environments usually produces misleading results.

Microsoft introduced Success by Design after observing recurring implementation failures across thousands of projects.

The framework focuses on identifying technical risks early in the project lifecycle.

Performance risks are one of the most common issues identified in architecture reviews.

Typical red flags include:

Success by Design encourages project teams to pause and evaluate these risks before it is too late.

Most Dynamics 365 performance issues are not caused by the platform.

They are caused by:

Cloud platforms provide elastic infrastructure, but they cannot compensate for inefficient design.

Performance testing is not a technical exercise.

It is an architectural validation of the entire solution.

Performance testing rarely appears on the project highlight reel.

But it quietly determines whether the system will succeed in production.

Projects that treat performance testing seriously:

Projects that ignore it often learn the lesson the hard way.

Usually on day one of go-live.

If you work with Dynamics 365 implementations, what has been the most common performance bottleneck you’ve seen?

Curious to hear real project experiences.