Insights & ideas

TL;DR:

A successful Dynamics 365 Finance and Operations migration isn’t just about moving records; it’s about creating alignment between business needs, legacy structures, and the new system’s logic. That requires collaborative scoping to define what really matters, treating data quality as a deliverable, documenting every field and transformation, and building a repeatable ETL pipeline with staged validation. Instead of a one-shot cutover, the process should be incremental and transparent, with weekly test loads, clear mapping, and active business involvement. Good tools like Azure Data Factory help, but methodology is what prevents the “six months became sixteen” scenario. Done right, migration gives your business a clean, functional start in Dynamics 365 — not just a new system with old problems.

Why most ERP data migrations go wrong — and how to make it work

ERP migrations have a reputation for being expensive, exhausting, and unpredictable. And it’s not just the big, global rollouts. Even small, focused projects can spiral.

A six-month timeline turns into sixteen.
Your customisations don’t fit cleanly.
Your “clean” data turns out to be anything but.

Sounds familiar?

That’s exactly why we’ve spent the past year refining a data migration playbook that works — especially for Microsoft Dynamics 365 Finance and Operations. It’s not flashy, but it’s structured, scalable, and realistic.

Let’s walk through what that actually means.

What does a “good” D365 F&O migration look like?

A solid migration process doesn’t just move data. It creates alignment between business needs, legacy structures, and the new system’s logic — and it makes that alignment visible to everyone involved.

Here’s what that looks like in practice:

Shared understanding from the start

‍
Kick off with collaborative scoping workshops. These sessions help define the core data entities, the essential fields, and the real business requirements behind each dataset. By the end, you’ve got a prioritised list of master, transactional, and configuration data — and a clear agreement on what matters at go-live.

Data quality as a first-class citizen

‍
Next, analyse source data for inconsistencies, duplicates, missing values, and odd formatting. This isn’t just about cleaning up typos — we’re talking about reconciling structure, aligning reference values, and spotting critical gaps before they break downstream processes.

Clear mapping, not just assumptions

‍
Every entity, every field, every transformation should be documented. Use an Excel-based mapping and metadata tracker that defines exactly how data flows from your old system into D365, including rules for enrichment, defaulting, and lookups. The goal is traceability and clarity, not guesswork.

A real ETL backbone

‍
The process is supported by a proper technical foundation. We use Azure Data Factory to orchestrate data movement, and Azure SQL as a staging layer with bronze, silver, and gold schema structures. These layers help us filter, transform, and validate data in stages, ensuring accuracy and referential integrity before anything lands in production.

Repeatable, testable load cycles

‍
Instead of a one-shot migration, use a gradual approach with weekly sprints to load data into test environments. Validate each cycle with smoke tests, basic process flows, and regression checks. This gives stakeholders the confidence that, come go-live, the data will actually support the processes it’s meant to.

But what about the dreaded stuff?

If you’ve browsed forums about ERP migration, you’ve seen it all:

“We thought it’d take 6 months. It took 16.”
“Our partner didn’t know how to handle our workflows.”
“The data blew up in size, and we got hit with surprise storage costs.”

These stories are real — and usually, the problem isn’t just the software. It’s the process. Most migration issues come down to underestimating three things:

• The complexity of legacy data

• The effort required to map custom logic

• The importance of incremental testing and validation

You can address these issues by making every step visible, documented, and testable.  

How we approach the D365 migration process

Here’s what our migration plan includes for customers switching to D365:

• A scoped, categorised list of entities, reviewed with business stakeholders

• A detailed mapping document with transformation logic, dependencies, and field-level rules

• A repeatable ETL framework using Azure Data Factory and SQL, with bronze–silver–gold architecture

• Weekly test loads with functional smoke tests and UAT-ready validation

• Structured cutover plans, including manual tasks, such as posting journals or setting up number sequences post-migration

• Azure DevOps for tracking tasks, bugs and decisions.

And once you’re live, we don’t disappear — we provide post-go-live support with daily check-ins, KPI monitoring, and issue triaging via DevOps.

Why optimising your ERP data migration matters now

Whether you're moving from a homegrown system, migrating on-prem, or finally replacing your 1980s-era ERP, the success of your Dynamics 365 rollout depends on how well you plan and document things. Good tooling helps — but good methodology makes the difference.

If you’re planning a migration (or in the middle of one and feeling stuck), let’s talk. Our process isn’t just about moving data — it’s about giving your business a clean, functional start in Dynamics 365.

Because no one wants to be the person saying “we thought it’d take six months…”

Need an experienced partner to overlook your ERP migration? Contact us for a free audit.

This is the first part of our series on ERP data migration. In the coming weeks, we will explore:  

• Reasons why your ERP migration is taking longer than expected,

• The importance of high-quality data management,

• Migrating ERP from legacy tech to D365, and

• The best practices for a successful ERP migration

‍

TL;DR:

Licence sprawl in Dynamics 365 happens when organisations scale across teams and regions without governance, leaving licences duplicated, unused, or misaligned. The result is wasted budget, security blind spots, and frustrated users who don’t have the right access. Licence sprawl isn’t a technology issue but a governance challenge that commonly appears in D365 environments. From using the Power Platform Admin Center to track consumption, to mapping licences by role with the CRUD framework, to auditing quarterly and planning licensing as part of expansion, licensing needs to be a strategic decision. The goal is to scale Dynamics 365 with confidence, reduce overhead, and stay compliant while avoiding the costly trap of overprovisioning.

The hidden cost of scaling Dynamics 365

A new team rolls out Dynamics 365 Field Service. Another office adopts Sales Enterprise. Someone adds 20 licences for ‘future hires’. Six months later, no one’s sure who’s using what or why.

As organisations scale D365 across regions, departments, and business units, licences often become fragmented, misaligned, or completely unused. As a result, you burn through your budget, users complain about not having the right access, and you’re stuck reviewing security blind spots that are difficult to track until something breaks — or the invoice arrives.

This isn’t a technology problem. It’s a governance problem. And the sooner you get a handle on it, the easier it becomes to scale Dynamics 365 with confidence.

This is the fourth part of our series on D365 licensing. In our previous article, we discussed  

• the basics of Dynamics 365 licensing and access management

• how to right-size your D365 license setup using the CRUD framework

• D365 vs. Power Platform and when to use them

What is licence sprawl in a D365 context?

Licence sprawl happens when Dynamics 365 entitlements are issued without oversight, tracked manually (if at all), and duplicated across environments. It’s common in distributed organisations, especially when each team or geography has its own IT lead or admin.

Symptoms include:

• The same user having multiple Dynamics 365 licences across production, test, and training environments

• Sales Enterprise licences assigned to users who only need to view reports or track leads

• Orphaned licences tied to inactive users still present in Entra ID

• Unused apps relying on expired trials, creating hidden points of failure

Dynamics 365 licences aren’t cheap. And because they’re often provisioned reactively, waste tends to go unnoticed, until a renewal forces the issue.

Can one user have multiple D365 licences across environments?

Yes. And it happens more than you think. But unless those users are performing different roles in different tenants (e.g. a test user vs. a live one), it's often a sign of poor governance.

For example, a user may have:

• Sales Enterprise in production

• Customer Service attach in a sandbox

• A Team Member licence in a separate region’s D365 instance

Multiply that by 50 or 100 users, and you’re looking at serious overhead.

How do we keep track of licences as we scale?

You don’t need to centralise everything. But you do need governance, structure, visibility, and accountability around how licences are issued, reviewed, and retired.

Here’s what that looks like in a D365-specific environment:

1. Use the Power Platform Admin Center (yes, even for D365)

‍
Dynamics 365 lives inside Power Platform, so your best source of truth is the Power Platform Admin Center. Use it to track:

• Licence consumption

• Environment assignments

• Storage usage (linked to licence tiers)

• Which apps and modules are being accessed and where

2. Align licences to roles, not names

‍
Don’t assign Sales Enterprise to someone just because they used to be in Sales. Map licences to job functions using the CRUD model (Create, Read, Update, Delete), and downgrade to Team Member or Power Apps where possible.

3. Audit your licensing estate quarterly

‍
Pull a report of:

• All assigned D365 licences by user and environment

• Last login dates to identify inactive users  

• Users with overlapping base and attach licences

• Sandbox environments with live entitlements that can be decommissioned

4. Implement a licence request process

‍
Require teams to justify licence requests with the user role and the needed D365 module. A simple form integrated into your onboarding flow can prevent dozens of untracked licence allocations over time.

5. Plan licensing before expansion, not after

‍
When you open a new office, launch a new service line, or deploy D365 to another region, licensing must be part of the rollout plan, not an afterthought.

Licensing isn’t just a cost issue, but a governance decision

Dynamics 365 is no longer just a CRM. It's a growing suite of enterprise apps: Sales, Customer Service, Field Service, Finance, and beyond. Each app comes with its own base and attach licence logic, storage rules, and entitlement limits.

And Microsoft is tightening enforcement. We’re seeing stricter validation around Team Member usage, environment capacity, and API limits, all tied directly to the licence model.

That means overprovisioning isn’t just a budget problem. It’s also a stability and compliance risk and should be treated as part of your broader governance strategy.

Smart licensing starts with visibility and intentional scaling

Licence sprawl in distributed D365 environments is costly. Without visibility, you risk duplications, unused licences, and non-compliance. Match licences to what users actually do, not what’s easiest to assign. Use admin tools to track who has access to what, and where. Make licensing part of your scaling strategy, not something you clean up later.

Need help scaling your D365 setup without exceeding your budget? Get in touch to discuss your use case.

‍

TL;DR

IT teams often face a recurring challenge: when should you build on Power Platform and when should you use Dynamics 365? Power Apps feel cheaper, faster, and more flexible, but without clear guardrails you risk rebuilding D365 from scratch, hitting licensing roadblocks, or paying twice for overlapping features. D365 and Power Platform share the same foundation but differ in cost models, out-of-the-box functionality, and roadmap alignment. The takeaway is not to choose one over the other, but to make intentional, use-case-driven decisions: use Dynamics 365 when you need depth, integration, and proven processes; use Power Platform when speed, flexibility, and cost control matter; and often combine both in a hybrid setup. The key is governance — aligning licensing and platform choice with real business needs instead of reacting case by case.

Are you rebuilding what you already own?

"We keep building custom Power Apps for everything — approvals, asset tracking, even sales processes. But are we just rebuilding Dynamics 365 from scratch?"

‍

Many IT Ops teams are stuck in a familiar loop: defaulting to custom Power Platform solutions because they’re faster, more flexible, or just feel cheaper. But somewhere along the way, you start to wonder: when does it actually make sense to use the out-of-the-box Dynamics 365 apps instead?

This is the third part of our series on D365 licensing. In our previous article, we discussed

• the basics of Dynamics 365 licensing and access management

• and how to right-size your D365 license setup using the CRUD framework

This post isn’t here to give you a magic answer (spoiler: there isn’t one). Instead, we’ll help kickstart the conversation with a few practical pointers, especially around licensing, and give you the clarity to make better decisions for your business and your budget.

When Power Platform feels like the obvious choice

Power Platform is gaining serious momentum. Go to any community event or conference and you’ll notice the shift: more sessions, more partners, more real-world stories. In many ways, Dynamics 365 tools are built on the same Dataverse platform. They share storage, governance, security, and admin tools. The main differences are their licensing and their out-of-the-box feature-set.  

So it’s no surprise many teams ask:

“Why pay £71.60/month for Sales Enterprise when I can build a tailored Power App for £4.10 per user or £16.40 per app?”

“Do we really need the full first-party app — or just a few of the features?”

“Why lock ourselves into Microsoft’s roadmap when we can create what we need ourselves?”  

They’re good questions. But they don’t always lead to the right outcome.

The challenge? You’re making decisions without the full picture

The core issue isn’t D365 vs. Power Platform. It’s not understanding the trade-offs,  especially when it comes to licensing.

Most teams don’t realise that D365 licences come with embedded Power Platform entitlements, or that standalone Power Apps licences don’t grant access to D365 apps or tables unless explicitly allowed.

So what happens?

You build a custom app. It works. Then a new requirement comes in like full Opportunity management or embedded AI suggestions, and suddenly, you hit a wall. Now you’re stuck either refactoring your app or backtracking into Dynamics 365, paying for features you’ve already replicated.

Meanwhile, no one’s really tracking whether your licence mix still makes sense.

Clarify the use case before choosing the tool

There’s no one-size-fits-all rule. But here are some guardrails that help.

Use Dynamics 365 when:

• You need rich, ready-made functionality (e.g. forecasting, SLAs, AI suggestions, complex case routing)

• You need proven process best practices, rather than designing and building them from scratch

• Your business processes match Microsoft’s domain models reasonably well

• You want native integrations with Microsoft tools like Outlook, Teams, LinkedIn Sales Navigator, or Copilot for Sales

• You’re okay with higher cost per user, in exchange for lower development overhead — depending on your specific needs

• You need certain customer features (e.g.: scheduling, webchat, or telephony integration)

• You are keen on getting Microsoft's new features and all the agentic/AI goodies coming our way

Use Power Platform when:

• You need to move fast, prototype quickly, or deliver something that doesn’t fit Microsoft’s mould

• You have lots of light-touch users who don’t need the full D365 UI or data model

• You want to create custom logic, UI, or automations that aren’t tied to first-party roadmaps

• You’re working in mixed environments where cost efficiency and control matter more than fancy out-of-the-box features
  

And here’s the thing: it’s not necessarily one over the other.

Combine both for flexibility

Most environments already do this, even if they don’t realise it. Dynamics 365 and Power Platform share environments. They share admin controls. They share security roles, Dataverse tables, and governance tooling. That means you can:

• Build custom Power Apps that live alongside D365

• Extend Dynamics with custom flows, plug-ins, and apps

• Use Power Pages for external users while keeping internal staff in Dynamics

• Mix licence types to match real usage (but make sure to avoid multiplexing)

The key is to align platform choice with actual team needs, not just what feels easier in the moment.

What about the future?

The Dynamics 365 vs. Power Platform debate is likely going to get even blurrier.

The number of partners shifting away from D365-first practices is growing. Some are openly saying they can build better, lighter-weight versions of Microsoft’s own apps using the same platform, without the first-party pricing.  

It’s clear the landscape is changing. Microsoft itself is pushing AI Agents, natural language interfaces, and modular, composable apps. The big SaaS era may be winding down, and that means your decision framework needs to adapt too.

Make the right choice for your business

There’s no universal right answer — only the right answer for your specific use case. A very high-level way to think of it:  

Use Dynamics 365 when you need depth, robust integration, and out-of-the-box functionality that’s purpose-built for business processes.  

Opt for Power Platform when agility, custom control, or cost flexibility are your top priorities.  

In practice, most environments benefit from a hybrid approach that leverages both. Just make sure you understand the licensing implications before you commit to one path or the other.

And above all: make the decision intentionally, not reactively.

Not sure which solution is best for your team? Get in touch to discuss your use cases.

Up next in our D365 Licensing series:  

• How to keep control over license sprawl in distributed teams

‍

TL;DR

Most Dynamics 365 environments are over-licensed because it’s easier to give everyone full access than map what they really need. That convenience quickly turns into wasted budget, as many users could be covered by cheaper Team Member or Power Apps licences without losing functionality. By starting with personas and using the CRUD framework to align licences with actual roles, IT Ops teams can right-size their setup, reduce costs, and stay compliant. The key is to differentiate between heavy users who need full Dynamics apps and light users who only need to read or update certain data. With the right governance, you avoid duplicate licences, reclaim unused entitlements, and make licensing a strategic lever for cost savings and smoother operations instead of an afterthought.

Full access to everyone? Why that D365 licensing shortcut costs you

“It’s easier to give everyone full access than figure out what they actually need.”

If that sounds like your current Dynamics 365 licensing strategy, you’re not alone. For many Operations teams, convenience wins: Full access for everyone, with little scrutiny.  

But that convenience comes at a cost.

One admin on Reddit realised that half of their 500 users likely didn’t need full Sales Enterprise licences. By reassessing needs and considering Team Member roles, they opened the door to major savings, without compromising on functionality.

This is the second part of our series. In our previous article, we discussed the basics of Dynamics 365 licensing.

In this post, we’ll show you how to avoid overspending by mapping licences to actual roles — not assumptions — using the CRUD framework and some simple steps.

Why most teams over-license by default

When you’re rolling out a CRM to a distributed workforce, many IT teams take the “just give them everything” approach:

• It’s quicker to provision

• It avoids user complaints

• It ensures access

But here’s the issue: most users don’t need everything. Let’s take field teams as an example:

• A sales rep logging notes or checking pipeline status? Probably fine with a Team Member or Power Apps licence.

• A dispatcher updating job status? Doesn’t need full Sales Enterprise.

Over time, these mismatches become expensive.

Start with personas, not products

Before assigning a single licence, step back and map your users by persona. Ask two questions:

1. What business role do they play? (e.g. Sales rep, dispatcher, technician)

2. What do they actually need to do in the system? (Use the CRUD framework: Create, Read, Update, Delete)
   

Then build a simple persona-functionality matrix. Here’s what that might look like:

Instead of starting with licence types, begin with actual user roles. This is an example of what it might look like:

Now you’re licensing based on what users do, not what they “might need someday”.

Use cases where Team Member or Power Platform wins

Let’s say you have:

• 10 partner managers or field reps managing opportunities full-time

• 100 extended team members like product, customer service, or sales support staff who just check status and log meetings

You don’t need 110 Sales Enterprise licences.

Instead, those 100 lighter users could use:

• Team Member licences for basic read/update interactions

• Power Apps per-user or per-app licences for custom tools

That change alone could lead to significant savings, while still enabling mobile access and compliance.

Don’t forget: Team Member licences have limits

Team Member licences are cost-effective, but they come with restrictions:

• Users can read any data but can only write to limited entities (e.g. contacts, notes, tasks)

• They’re limited to one Dynamics 365 app module and one custom app

• They don’t support premium plug-ins or complex automation

Tip: Create simple, dedicated apps for Team Member roles. For example, a “Sales Assistant” app that restricts functionality to what’s permitted.

Power Platform: The underrated licensing play

If your field users mostly use custom mobile apps — say, to:

• Record visit results

• Complete inspections

• Trigger automated workflows

…then they may not need a Dynamics 365 licence at all.

Instead, use Power Apps licences to:

• Access the same Dataverse instance (as long as those apps don’t rely on restricted entities like some Sales or Service records)

• Work with custom tables

• Run Power Automate flows

• Keep licensing flexible and compliant

For many field teams, this is the simplest way to reduce licensing costs while improving the user experience.

What to do next: Your 2025 licence optimisation checklist

• Audit your current licence usage
  Start with heavy vs. light users. Who really needs full access?

• Map access by role
  Build a persona-to-functionality matrix using the CRUD model (Create, Read, Update, Delete).

• Reassign based on real needs
  Don’t rely on legacy assignments. Right-size licences to fit current roles.

• Use Team Member licences wisely
  Apply only where read-only, self-service, or basic update access is sufficient.

• Deploy Power Platform licences
  Great for users who only need custom apps or limited interactions.

Avoid common traps

• Don’t use Power Apps licences to access D365 restricted entities
  Be careful: Sales, Field Service, Customer Service features and restricted entities are off-limits.

• Avoid duplicate licences across environments
  Check for sandbox or legacy orgs assigning unnecessary extra licences.

• Reclaim unused entitlements
  Track who actually logs in and remove licences from inactive or former users.

• Watch for multiplexing violations
  Sharing a single account across multiple users via Teams, SharePoint, or embedded apps? This is not allowed, and Microsoft is tracking it.

Licensing impacts more than your budget

Licensing isn’t just a budgeting decision — it’s an operational one. The wrong licence can block users, slow down processes, or waste tens of thousands annually.

Matching licences to how people actually work can reduce spend, streamline provisioning, and improve satisfaction for your mobile workforce.

Need help auditing your Dynamics 365 environment? Contact us to discuss your use case.

Up next in our D365 Licensing series:  

• D365 or Power Platform: Which one is right for your use case?
• How to keep control over license sprawl in distributed teams

‍

Disclaimer: This post is for informational purposes only and does not constitute formal licensing advice. Microsoft licensing is complex and subject to change — always refer to the official Microsoft Licensing Guides and consult with a qualified advisor (like us!) before making decisions.

‍

‍

TL;DR

Licensing issues are one of the biggest hidden causes of access problems in Dynamics 365. Even when users are assigned licences, they may still be blocked by missing environment permissions, misapplied base and attach licences, or silent capacity limits. For IT Operations teams, understanding the fundamentals — user, device, and tenant licences; base vs. attach logic; storage entitlements; and environment constraints — is key to keeping systems stable and budgets under control. Most over-spend comes from duplicate base licences, orphaned entitlements, or unused capacity left in old environments. Treat licensing as part of your core governance strategy, not an afterthought: map roles to licences, audit regularly, and align capacity with actual demand. Done right, licensing prevents downtime, keeps users productive, and ensures compliance as Microsoft tightens enforcement in 2025.

Dynamics 365 access: Is it a licensing issue or something else?

"We assigned the licence. Why can’t they log in?"

‍

For many IT Operations teams, managing Dynamics 365 feels like tiptoeing through a minefield of licences, environments, and entitlements.

One admin summed it up like this:

“We’re paying for licences, but people still can’t access what they need. I just want to keep the system running.”

Dynamics 365 licensing is confusing but makes sense once you understand the principles. Between base licences, attach licences, user vs. capacity models, and silent limits on environments, even experienced IT pros get blindsided.

This is the first part of our Dynamics 365 licensing series. In this post, we’ll break down the key licensing concepts that matter for IT operations in 2025, without repeating the entire Microsoft guide.

Why your users have licences but still can’t access D365

Let’s start with the most frustrating scenario: your users are licensed, but they still hit access errors.

Here’s why that happens:

• A licence doesn’t guarantee access to the environment. Users need permissions to the right environment and the underlying database.

• Some roles need more than one licence. A single app licence (like for Finance) might not be enough if the user also needs to work in another module (like Sales).

• Attach licences only work if you have a valid base licence. You can’t stack attach licences on a user without a qualifying base licence in place.
  

And don’t forget: environments and storage come with limits too. If the environment is out of capacity or misconfigured, licensing won’t save you.

D365 licensing basics

Here’s what actually matters to IT Operations teams:

The three licence types you’ll encounter most

• User licence: The most common. Tied to a named user.

• Device licence: For shared workstations or kiosks, especially in warehouses or retail.

• Tenant licence: Grants capacity (like storage or API calls) at the environment or tenant level.

Base vs. Attach licences

• Base licence: The first licence a user gets. It must be the most expensive one they need.

• Attach licence: Discounted licences for additional apps. Only valid if you have a base licence from the right product family.

Many teams overpay by assigning multiple base licences instead of using attach licences strategically.

“We’re cleaning up old users — what do we do with the licences?”

This is a common scenario. Old users are still active in Entra ID or assigned licences in the Microsoft 365 Admin Centre, but nobody’s checked if they even use the system.

Here’s what we recommend:

• Audit licence assignments quarterly. Look for inactive users still assigned premium licences.

• Clean up orphaned access. If a user has been removed from Dynamics but still exists in Entra ID with a licence, that’s wasted spend.

• Map access by role, not by person. Don’t assign licences just because “that’s what they had before.” Reassess by function.
  

Start with Team Member licences for light users — just make sure their access needs fall within its limits (read-only, self-service, or basic workflows only).

Are we paying for duplicate licences across environments?

Short answer: probably. Here’s how to spot waste:

• Check for users with licences in multiple environments, especially sandbox copies or legacy orgs that no one cleaned up.

• Review capacity add-ons — many are environment-bound and often over-provisioned.

• Look at attached Power Platform licences. Are you paying for capacity through both Dynamics and Power Apps? You might be.

Storage maths in a nutshell

• Each full user licence gives you 10 GB of database storage

• Every user adds 250 MB extra

Need more? You’ll have to buy additional capacity.

Three tech stacks = three licensing mindsets

Dynamics 365 isn’t one piece of software or application. It’s a suite with different behaviours and pricing models:

1. Customer Engagement Apps: Sales, Customer Service, Field Service — often used together, but watch out for duplicate entitlements.

2. Business Central: Sold as a bundle. Easy to manage, but not as flexible with attach licences.

3. Finance and Operations: High-value, high-cost — and the source of many of the trickiest licence combinations (Finance alone is £180/user/month).
   

Each stack handles users, storage, and automation differently. If you’re mixing these, map your licensing strategy accordingly.

Licensing isn’t just compliance

Many access issues, slow processes, or broken workflows are actually licensing issues in disguise:

• Overloaded storage = system slowdowns

• Misassigned licences = user lockouts

• Missing entitlements = failed automations

Licensing is now directly tied to performance. Microsoft is enforcing this more aggressively, especially for Team Member misuse and capacity overages.

Your 2025 checklist for cost-efficient Dynamics 365 licensing

• Audit users and licences: Identify who has what, where, and whether they actually use it.

• Map roles to licence types: Use role-based access and the CRUD model to assign only what’s needed. (More on CRUD in our next post!)

• Use Attach licences wisely: Don’t pay for multiple base licences — add attach licenses where eligible.

• Clean up unused environments: Retire or merge low-use or duplicate instances.

• Align storage to actual need: Remove excess capacity and avoid default overprovisioning.

• Consolidate across teams: Prevent duplicated licensing in siloed regions or departments.

• Reclaim unused licences: Remove entitlements from inactive or former users.

• Review quarterly: Make licence audits a recurring practice, not a one-off cleanup.

• Monitor Microsoft policy changes: Stay compliant by keeping up with evolving licensing rules.

Don’t let licensing be an afterthought

You don’t need to master every nuance of Microsoft’s licensing. But you do need to understand the mechanics that impact performance and budget.

Licensing should be among the first priorities in your Dynamics 365 environment, right alongside security, data, and automation.

Need a health check on your setup?
Request a free audit and make sure you’re not leaving money (or performance) on the table.

Up next in our D365 Licensing series:  

• How to right-size your D365 licenses by aligning them with actual user roles

• D365 or Power Platform: Which one is right for your use case?

• How to keep control over license sprawl in distributed teams

‍

TL;DR:

Copilot Studio has officially moved out of the Power Platform Licensing Guide into its own dedicated document — a quiet but meaningful change introduced in June 2025. While the usage-based model remains the same, the separation signals Microsoft’s shift toward standalone, consumption-driven pricing for AI tools. Copilot Studio now has its own guide detailing billing rates, usage estimators, and agent activity costs, while all major references have been removed from the Power Platform guide. For IT operations and licensing teams, this marks the start of a broader transition to pay-per-use models across Microsoft’s ecosystem. Keep both guides updated, watch for usage-based billing creep, and prepare for renewals that reflect this new AI-first licensing era.

New guide, same usage-based model

There’s been a quiet but important shift in Microsoft’s licensing documentation. If you’ve been tracking the Power Platform licensing guide over the past few months, you might have noticed something in the June 2025 edition: Copilot Studio is gone.

In short: Copilot Studio has “graduated” out of the Power Platform PDF and now lives in its dedicated guide.

As Jukka Niiranen noted, Microsoft has released a dedicated Copilot Studio Licensing Guide that consolidates information previously scattered across Microsoft Learn articles, pricing pages, and various Power Platform PDFs.

There was no formal announcement of this change, just a quiet footnote in the June 2025 Power Platform change log:

"For Microsoft Copilot Studio licensing information, please refer to the Microsoft Copilot Studio Licensing Guide."  

What’s in the new guide?

• How to buy Copilot Studio

• Billing rates for agent activity and AI tools

• A usage estimator

• Licensing scenarios (e.g. trials, enterprise deployment)

• Details on Dataverse, Managed Environments, multiplexing

• Appendices on billing, preview terms, terminology and change log

And what’s changed in the Power Platform guide?  

As Jukka pointed out, most references to Copilot Studio have now been removed. Only a few mentions remain in the change log, likely a sign that the transition is still in progress.

Importantly, there are no changes to the underlying licensing model at this time. Copilot Studio continues to follow usage-based billing:

• Agent messages

• AI tool calls

• API usage

All contribute to billed consumption.

Why it matters: Are we phasing out Power Platform… or phasing in pay-per-use?

This might seem like a minor update to documentation, but it points to a bigger shift. Microsoft is carving out its high-value tools like Copilot Studio into standalone billing structures, separate from the Power Platform umbrella many organisations still depend on.

In a LinkedIn post, Roberto Lofaro recalled earlier transformations in software licensing:

• From 1980s maintenance fees (that sometimes continued even after updates stopped),

• To project-based and license-based SaaS in the 1990s,

• To today’s consumption-first models.

We’re moving closer to a model where AI features become embedded in every desktop and mobile tool and incur usage charges whenever they connect to cloud services. Think of Copilot in Office or even WhatsApp integrations that quietly activate background AI.

In Roberto’s words, "It is almost a Chromebook model: you can activate the offline use, but will lose features”.  

In short, key features will only work when connected, and often at a cost.

What to watch out for (especially if you're in IT Ops)

As Copilot Studio moves into its own licensing framework, here are a few things to keep on your radar:

• Update cycles: Don’t rely on the Power Platform guide alone. Keep track of the standalone Copilot Studio guide, it is likely to receive more frequent updates.

• Broken references: If your internal documentation or procurement materials still reference Copilot Studio under Power Platform, it’s time for an update.

• Pay-per-use creep: Be cautious about where AI usage might trigger billing. Even features that seem low-touch may generate billable events.  

• Preview ≠ free: Not all preview features are cost-free. Some already contribute to billed usage, especially in environments with connected data.

Keep track of your usage. You can use the Copilot Studio agent usage estimator (still in preview).

Your next Microsoft renewal might look very different

Microsoft is reorganising its licensing playbook to support an AI-first future. Copilot Studio getting its own guide is more than a formatting choice — it signals a broader shift toward usage-based pricing models.

If you’re involved in IT operations, licensing, or governance, keep an eye on these developments. Especially before your next renewal.

The bottom line is: Microsoft’s pricing structure has been changing a lot recently. Want to optimise licenses before your upcoming renewal? Contact us to discuss your use case.

‍