Dynamics 365 is the most module heavy and most over licensed product in the Microsoft stack. Sales, Customer Service, Finance, Supply Chain, Field Service, Business Central, and Customer Insights each carry their own SKU map, attach license rules, and team versus full user pricing. We map the actual user motion against the entitlement matrix, retire what is not used, restructure what is, and negotiate the contract around the footprint that fits. 34 Dynamics engagements. Median spend reduction north of 26 percent.
Dynamics 365 is licensed at the user level, the module level, and in some cases at the device level. The licensing model rewards customers who classify users correctly across full versus team, primary versus attach, and named user versus device. The same user count produces dramatically different invoices depending on classification. In most engagements, the customer is classifying for compliance safety rather than economic accuracy, which is the same as overpaying.
The Dynamics 365 Team Member license is a reduced functionality SKU that covers read, light update, and approval scenarios across most modules. It is materially less expensive than a full user license. The Microsoft seller will not aggressively position Team Member because doing so reduces the contract value. The buyer side analysis maps actual usage motion per user and reclassifies the population accordingly.
Across the practice, the median enterprise overstates its full user count by 30 to 40 percent at the start of the engagement. The corrected mix unlocks substantial recurring savings without changing what any user can actually do in the system.
Customers who hold a primary Dynamics module (Sales or Customer Service) qualify for attach pricing on additional modules at meaningfully reduced unit cost. The seller’s quote often defaults to non attach pricing across the portfolio, which is correct only if the customer has no primary module. The cost differential is significant on multimodule deployments.
We map the module roadmap, identify the correct primary anchor, and restructure the quote so that every additional module is attached to that anchor. The contract structure follows the actual deployment topology, not the seller’s invoice convention.
The Dynamics work runs through a sequence of three lenses, each of which exposes a different class of misalignment.
Who in the organization touches Dynamics, in what role, with what frequency. The persona map is the precondition for everything that follows.
What each persona actually does in the system. Read only, update, approve, configure, administer. The motion determines the license class.
Which modules each persona touches, what the primary module should be, and how attach licensing reshapes the contract structure.
The negotiated unit price, the multiyear ramp, the future module rights, and the exit language for modules that may be retired mid term.
Finance and Supply Chain Management are the two highest unit price SKUs in the Dynamics portfolio. They are also the modules where the persona segmentation produces the largest dollar swings. Most enterprises hold full Finance or SCM licenses on populations that touch the system once a quarter for an approval or a report.
In Finance and Supply Chain deployments, the typical population breakdown that emerges after motion analysis is roughly 35 percent full user, 50 percent team member or Operations Activity, and 15 percent neither (system identities, retired accounts, contractors no longer engaged). Customers who started with uniform full user licensing are by definition overpaying on at least 65 percent of the seat count.
The reclassification work is mechanical but slow. Each user needs evidence of their actual motion. The system telemetry is the source of truth. Once the reclassification is complete, the unit price negotiation is held against the smaller, properly classified count, which compounds the savings.
The Operations Activity license is a relatively recent SKU that covers light update motions in Finance and SCM at a fraction of the full user price. It is consistently undersold by the seller, who has weak incentive to surface it. We map the eligible population, restructure the contract, and lock the unit price.
Dynamics Finance and SCM deployments take 12 to 24 months to reach steady state. Customers who commit to full user counts on day one are paying for users who will not be active for a year or more.
We negotiate ramp structures that align license activation with go live dates per business unit, defer start dates for delayed phases, and protect the customer against schedule slips on the implementation side that should not flow into the licensing side.
Anonymized but verifiable on reference call.
The customer held uniform full user licenses across 4,200 seats on Sales, Customer Service, and Finance. We mapped the motion data, reclassified 2,600 users to Team Member, identified Sales as the correct primary anchor, restructured the attach pricing on Service and Finance, and negotiated a multiyear ramp that aligned with the Finance go live schedule.
Nobody lost a capability they were using. The bill went down because the contract finally described what we actually deployed.Director of Enterprise Applications · Industrial manufacturer
The Dynamics seller will say Team Member is a downgrade. It is not a downgrade. It is the SKU that matches the user.Managing analyst · Dynamics practice
Business Central is the small and mid market Dynamics SKU, designed to compete with QuickBooks, Sage, and similar platforms. For enterprises that acquired a Business Central deployment through a subsidiary or smaller business unit, the licensing conversation is fundamentally different from the Finance and SCM conversation. Different SKU map, different per user pricing, different attach rules.
Business Central is the correct SKU for sub 250 user deployments running standard business processes (general ledger, AP, AR, inventory, basic procurement) without heavy customization. Above 250 users or with significant customization, the Finance plus SCM combination almost always lands at better total economics despite the higher unit price, because the enterprise SKU set scales without the per user overhead Business Central accumulates.
Enterprises that inherited Business Central through acquisition often hold the deployment past the point where it remains the right SKU. The right answer is migration to the enterprise stack at the next renewal cycle, with the contract structured to capture both the migration economics and the ongoing Finance plus SCM unit price.
Microsoft seller incentives are structured to retain Business Central revenue, not to migrate it to the enterprise stack. The customer that needs to migrate will receive a renewal proposal that preserves the Business Central footprint and adds enterprise modules alongside it, which is the worst possible configuration. The customer ends up paying for both SKU sets while consolidating onto neither.
The buyer side conversation forces the migration decision. Either the deployment stays on Business Central with no enterprise overlap, or it migrates fully to Finance plus SCM with Business Central retired on a defined timeline. The contract structure follows the decision. We do not negotiate against ambiguity.
Beyond the core Sales, Service, Finance, and SCM modules, the Dynamics portfolio includes Customer Insights (the CDP and marketing layer), Field Service (the field technician dispatching layer), and Project Operations (the professional services layer). Each carries its own pricing model, its own seller incentive structure, and its own optimization opportunity.
Customer Insights is positioned as the customer data platform that unifies behavioral, transactional, and demographic data into a unified customer profile for marketing and service activation. For customers that consolidate onto Customer Insights, the savings against legacy CDP vendors (Adobe, Salesforce Data Cloud, Treasure Data) can be substantial. For customers that license Customer Insights alongside an incumbent CDP, the spend is purely additive.
The buyer side analysis tests the consolidation thesis explicitly. If the incumbent CDP cannot be retired within the renewal window, Customer Insights should not be on the contract. If it can, the contract should be structured to capture the incumbent retirement economics and to protect the customer against schedule slip on the migration side.
Field Service and Project Operations are vertical specific modules. The licensing analysis depends on whether the customer’s operating model actually fits the module’s assumed workflow. Many customers license these modules and then implement workflows that diverge significantly from the module’s native model, which produces poor adoption and high customization cost. The license decision should follow a candid workflow fit assessment, not the seller’s capability framing.
Microsoft introduced Copilot for Sales, Copilot for Service, and adjacent AI capabilities on top of the core Dynamics modules in 2023 and has expanded the catalog quarterly since. The pricing is structured as per user attach on top of the base Dynamics license, with material unit price impact at scale.
The deployment math for these AI capabilities follows the same persona based discipline as M365 Copilot. The capabilities deliver measurable value for specific user populations and limited value for the broader Dynamics user base. The contract structure should allow targeted deployment, not uniform tenant assignment.
Many enterprises hold their Dynamics contracts on a separate anniversary from the broader EA, often as an artifact of the original Dynamics implementation predating or postdating the EA renewal cycle. Co terming the Dynamics contract into the EA at the next renewal opportunity is one of the highest leverage structural moves available to enterprises with mature Dynamics deployments.
A blended renewal that combines EA, Dynamics, Power Platform, and Azure into a single agreement is the configuration Microsoft offers the deepest concession against, because the deal desk has more surface to defend the headline number and the seller has a larger commit to land. The customer captures concession depth, structural language consistency, and operational simplicity across the contract estate.
The co term itself often requires negotiating a partial year extension or contraction on one side to align the anniversaries. That negotiation is a discrete commercial event with its own concession opportunity. We handle the co term and the renewal as two phases of the same engagement.
Co terming is not always the right move. Customers in active Dynamics migration, with significant in flight implementation work, or with materially different Dynamics consumption trajectories from the rest of the estate are often better served by holding the Dynamics anniversary separate. The fragmentation cost is real, but it is lower than the cost of locking a misshapen Dynamics footprint into a multiyear blended commit.
The decision is engagement specific. We model both scenarios explicitly and recommend the structure that produces the best total economics over the next three years, not the structure that is operationally cleanest at signature.
Customers running Dynamics 365 in production alongside Dynamics on premises (typically Dynamics 365 Customer Engagement and Dynamics AX or NAV legacy estates) carry dual use rights that the seller rarely surfaces. The rights allow concurrent on premises and online use of the same workloads under defined Software Assurance conditions, and they can defer or eliminate significant migration cost during a phased transition.
For customers in the middle of a Dynamics modernization, dual use rights allow the on premises footprint to remain in production while the online deployment scales up, without double licensing the user population. The seller will not surface this unless explicitly asked, because dual use defers commitment to the online estate. The buyer side conversation forces the conversation and captures the migration cost cushion the customer is entitled to.
The rights expire at the end of the transition window defined in the agreement, which is typically twelve to twenty four months. The contract restructure needs to define that window explicitly and align it with the realistic migration schedule, not the seller’s preferred acceleration timeline.
Dual use is a transition right, not a permanent configuration. Customers who hold dual use indefinitely accumulate compliance exposure as the rights expire and the on premises footprint persists. The buyer side recommendation is always a defined transition timeline that closes dual use cleanly, with the contract structured to capture the savings on the closure side.
The closure conversation is also the right moment to negotiate the perpetual on premises license retirement, the Software Assurance lapse, and any residual support obligations. We bundle these into the transition close to minimize the long tail compliance footprint.
Two analyst calls. No pitch. We tell you what we would do, what the leverage actually is, and whether we are the right firm for this engagement.