Insights & ideas

ERP migrations don’t fail because of bad software. They fail because too many teams treat them like an IT task, not a business transformation.

Many teams see their Dynamics 365 migration drifting past deadlines, or costs creep up while progress stalls. Even well-scoped projects with strong business cases run into blockers.

Here’s what we’ve learnt after seeing (and guiding) dozens of ERP migration projects:
Delays usually start with data. But the root problem is bigger — it’s a lack of upfront alignment between data, process, and ownership.

This is the second part of our series about ERP migration. In our previous article, we shared our playbook for a successful migration.

Four reasons your ERP migration is falling behind

1. Unmanaged customer and vendor data

Most legacy systems are bloated. One client we worked with had over 16,000 customer records, but only 2,700 were active. The rest were either duplicates, stale entries, or test data nobody cleaned up.

If your team doesn’t decide what to migrate and why before the project starts, you’re setting yourself up to move a mess from one system to another. And in Dynamics 365, that mess costs you — in time, storage, and performance.

2. No data readiness plan

Too many projects start with: “We’ll clean the data as we go.”

But once integrations begin and deadlines approach, that plan gets dropped. Then problems surface late: incorrect tax setups, mismatched payment terms, missing inventory units. These are all issues that weren’t visible until they broke something in testing.

Without a readiness plan, your team ends up fixing issues reactively. That’s when rework kicks in, timelines double, and your team’s confidence plummets.

3. Dirty data, no ownership

Inconsistent customer names. Duplicate vendors. Blank fields in mandatory columns. This is what we see when no one owns the data and no one’s accountable for fixing it.

ERP migration isn’t just about moving fields between tables. It’s about aligning business-critical records with how your new system is supposed to work. That takes decisions, not just scripts.

4. No dedicated migration team

One of the biggest red flags? When data migration is assigned “as a side task.”

ERP migrations affect every business unit. But many companies staff the project like it’s a back-office upgrade, until go-live panic sets in and suddenly, every department is firefighting data issues that should’ve been solved months ago.

What to do instead — A better way to plan your Dynamics 365 migration

Build a real data strategy before you migrate

Start by asking:

• What data do we actually use?

• What do we need to keep for compliance?

• What can we safely archive?

Then structure it for Dynamics 365. If you’re using Finance and Operations, that might mean reviewing data entities in the Data Management Framework, validating reference tables, and making sure your master data aligns with global address book logic.

Don’t wait for developers to ask these questions mid-project. Answer them early with business owners in the room.

Treat migration as transformation, not a lift and shift

The way you quote customers, manage stock, or post invoices might evolve in D365. So involve business process owners before you start migrating records.

Work backwards from your future-state workflows. Ask what data supports those processes, and define what needs to change, structurally, not just technically.

This approach helps avoid surprises later, like finding out your old pricing model doesn’t map cleanly to the new sales order flow.

Clean, enrich, and validate data upfront

Treat data quality as a project deliverable. Assign owners for each dataset — customers, vendors, products — and give them time to review, correct, and enrich records.

Use validation runs in a test environment to catch issues early. We typically run weekly load cycles into a staging environment, using Azure Data Factory + SQL with a bronze–silver–gold architecture to control quality step by step.

Allocate real resources early

Your best functional experts should be part of the migration team. If they're only looped in at go-live, they’ll spend weeks untangling misaligned setups that could’ve been avoided.

This isn’t just an IT project. It’s a business-critical initiative. Treat it like one.

TL;DR: You can still get back on track

If your ERP migration feels stuck, it’s not too late, but the fix probably isn’t more developers or another integration patch.

It’s a shift in how you’re planning, resourcing, and governing the work.

• Define a clear data strategy

• Align migration to business process transformation

• Assign data owners and validate early

• Treat migration as a dedicated workstream, not an afterthought

Our clients turn to us to get a structured approach tailored for Dynamics 365 — so if you’re feeling stuck with your ERP migration or planning one, let’s talk.

‍

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

‍

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.

‍

"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.

‍

“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.

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.

‍