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.

‍

‍

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.

Instead, it now lives in its own dedicated guide.

New guide, same usage-based model

In short: Copilot Studio has “graduated” out of the Power Platform PDF. 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.

‍

Scaling your Power Platform usage is a good problem to have. It means your teams are building, automating, and delivering value.  

But unchecked growth comes with hidden costs. As Microsoft evolves its licensing models, small missteps can snowball into big expenses.

In this blog post, we discuss how to scale in a sustainable way, design cost-aware apps, and stay in control as pricing and features shift. Whether you’re running a Center of Excellence or simply supporting teams building apps, the goal is the same: grow smart, without overspending.

This is the fifth part of our Power Platform licensing series. In our previous articles, we covered

• Microsoft Power Platform licensing changes in 2025 and how they affect users,

• Power Platform Licensing Within M365 & D365 and what bundled access actually includes

• Standard vs. Premium Connectors in Power Platform and how to stay ahead of changes

• Request management in Power Platform and how to stay within limits and budget

Stay informed: Monitoring licensing and usage

One of the most important habits you can build is regular visibility into what you’re using and what it costs. Microsoft licensing isn’t static — new SKUs are introduced, entitlements change, and API pricing evolves behind the scenes. If you’re not watching, you’ll miss the early signs of budget creep.

Start by subscribing to Microsoft’s release notes and licensing update blogs. These updates often include connector reclassifications or entitlement adjustments that can quietly impact your costs. Set internal reminders to review licensing guidance at least once per quarter.

On the internal side, the Power Platform Admin Center provides recent usage data to help you:

• Track how many users are actively using licensed features

• Identify which apps or flows are consuming the most requests

• Flag spikes in usage that could trigger overages

While Azure Monitor doesn’t directly track Power Platform request usage, it can complement your monitoring strategy by alerting on related Azure services, such as API Management or custom connectors, based on available metrics and logs.

This isn’t just about control, but also about building confidence that your investments are being used effectively.

Build apps with the future in mind

Great app design doesn’t just improve performance, it also reduces risk when licensing rules change.

When building or reviewing solutions, favour modular architecture. Why?  

Modular apps are easier to adapt if Microsoft reclassifies a connector or changes how a feature is billed. For example, separating a high-volume automation into its own flow makes it easier to isolate and scale independently.

Be strategic about Premium connector usage. If your team already relies on connectors like Dataverse, SQL Server, or custom APIs, continue using them where they add value. But if you're considering Premium for the first time, evaluate whether the business impact justifies the added cost. Either way, design flows to avoid unnecessary steps or repetitive API calls that can drive up request consumption.

As part of your development standards, document each app’s licensing and connector dependencies. When it comes time to upgrade, scale, or refactor, this documentation will save time and prevent guesswork. If you're using the Center of Excellence Starter Kit, it automatically tracks which connectors each app and flow uses — and whether they’re Standard or Premium.

Run regular health checks for smarter spending

Apps and flows don’t stay static and neither should your approach to managing them.

Establish a regular cadence for cost and usage audits. Monthly or quarterly reviews can reveal:

• Licensed apps that haven’t been used in months (“zombie apps”)

• Flows that run frequently but no longer serve a real purpose

• License assignments that don’t match actual user activity

You’ll also want to conduct scaling impact reviews. What happens if app usage doubles next month? Or a department adopts Power Platform for the first time? Use Microsoft’s licensing calculators and cost simulators to predict these shifts before they happen. A little forecasting now can save you a budget surprise later.

Avoid lock-in while leveraging the ecosystem

When scaling on Power Platform, it’s tempting to take full advantage of every integration and customisation feature available. That’s the power of the platform, but it can also create hidden long-term costs.

There’s a difference between vendor alignment and vendor lock-in.

Alignment means taking advantage of Microsoft-native tools like Dataverse, Teams, and Azure for greater cohesion. Lock-in happens when your solution becomes so custom that migrating or adjusting becomes painful or expensive.

Whenever possible, keep business logic inside Power Platform, but design your data to be portable. Avoid overly rigid dependencies on proprietary formats or niche connectors unless they’re business critical.

Audit the tools you’re already paying for

Another source of cost creep is tool redundancy. Teams often spin up new software without realising that the same functionality exists within the Power Platform or adjacent Microsoft 365 tools.

Make it part of your governance model to review the full ecosystem regularly. Ask:

• Are multiple analytics tools in use across the same team (e.g., Power BI and Tableau)?

• Are there legacy tools still active despite being replaced by Power Apps or Automate?

• Are business units buying new solutions instead of using licensed ones already available?

Encourage teams to maximise existing investments before expanding into new tools.

Assign ownership to stay ahead

One of the most effective things you can do to control costs is assign a cost and usage owner. Without clear ownership, monitoring tends to fall through the cracks, especially when budgets are shared across departments.

This person (or small team) doesn’t need to manage licenses day-to-day. But they should be responsible for:

• Tracking usage trends

• Monitoring request volumes and license consumption

• Preparing quarterly usage reports

• Advising on renewals, upgrades, or plan changes

Proactive cost management is only possible when someone is paying attention to the right data at the right time.

Final thoughts: Maximise value without overspending

Scaling Power Platform doesn’t have to mean growing your budget at the same pace. With the right practices in place, you can expand your impact while keeping costs predictable and controlled.

Keep these principles in mind:

• Monitor usage regularly and stay up to date with licensing changes

• Design apps with flexibility and long-term efficiency in mind

• Assign ownership so cost and usage insights turn into action

Smart scaling isn’t just about handling growth, it’s about making every cent you spend work harder.

We hope you’ve found our series on Microsoft Power Platform licensing helpful.

Looking to scale your Power Platform usage without overspending? Contact us to discuss your use case.

‍