Legacy Fixed-Price Dynamics 365 Contracts Losing Margin: What Delivery Data Can Fix

When old fixed-price Dynamics 365 contracts are losing margin, start with the measurement, because any later conversation needs it. Reconstruct the effort actually delivered against each contract scope from time entries and ticket data, and show which change requests were absorbed rather than billed. Then stop further leakage with a change-control gate that classifies and approves every request before work starts. Estimate new work through fixed-scope pilots or phased work packages rather than a single large price. Finally, look at the cost side of delivery, including whether subcontracted senior capacity is cheaper to carry than a bench. This note covers those delivery steps only, not how to renegotiate the contracts themselves.

Say this plainly before going further: contract renegotiation, legal terms, pricing strategy and client commercial relationships are outside Solzet's expertise, and nothing in this post is legal or commercial advice. Take those questions to your commercial leadership and legal advisers. What we can speak to, from 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, is how the delivery evidence is produced, how scope leakage is stopped and how the cost of delivery changes with the way it is staffed.

Why do legacy fixed-price Dynamics 365 contracts lose margin over time?

Usually not through one bad estimate but through slow drift that nobody measured while it happened. The common delivery-side causes are these:

• Scope written at a level of detail that let reasonable people disagree, such as "configure case management", so each new requirement could be argued in scope.
• Small change requests absorbed to keep the client happy, each one too small to raise, collectively larger than a phase.
• Support or managed service commitments that assumed a stable system, while the solution kept growing and every Microsoft release wave needed regression testing.
• Rework from defects, unclear requirements or turnover in the delivery team, with knowledge leaving each time someone did.
• Client dependencies, such as late data, delayed testing or changing decision makers, that extended the work without extending the contract.
• A cost base that rose, through salaries and bench time, while the contract price stayed where it was signed.

Some of these are the client's doing, some are the partner's, and most are both. That matters for what comes next.

How do you reconstruct delivered effort against the original scope?

Build one table that joins what was sold to what was done, from records that already exist, and classify every piece of work by rules written before anyone looks at the totals.

1. Break each contract into scope lines: the statement of work, its appendices, agreed specifications and any change orders that were formally signed. Give each line an identifier.
2. Collect the delivery records for the contract period: time entries from your timesheet or professional services system, work items and bugs from Azure DevOps, Jira or your support tool, and where time entries are thin, solution and source control history, release notes and meeting records.
3. Link each work item and its logged effort to a scope line, or mark it as not traceable to one.
4. Classify each item: original scope, change absorbed without a change order, defect in delivered scope, rework caused on your side, delay or rework caused by a client dependency, or unclassified.
5. Have two people classify a sample independently and compare, then fix the rules where they disagree before classifying the rest.
6. Summarise effort by contract, scope line and classification, and list the absorbed changes individually with dates, requester and effort, because a named list is far more useful than a total.

Be ready for the evidence to cut both ways. A reconstruction that shows only client-driven scope growth will not be believed. One that also shows estimating gaps, rework and team turnover on your side is honest, and it tells you which part of the loss a better delivery process can recover and which part it cannot.

What makes delivery evidence credible to a client or an adviser?

Traceability and restraint. Each figure should lead back to a ticket, a time entry or a document, and the method should be written down so someone else could repeat it.

• Use the records as they were, and do not recode or retime history to strengthen the case. Where data is missing, say so and show the gap rather than estimating it silently.
• Separate effort that is well evidenced, such as linked tickets with time logged, from effort that is inferred, such as time booked to a general code.
• Show absorbed changes as the requests they were, with who asked and when, not as a percentage of overrun.
• Keep your own rework in the same table as client-driven change.

How that evidence is used in a conversation with the client, and what should be asked for, is a commercial and legal question for your own leadership and advisers.

How does a change-control gate stop further margin leakage?

By making it impossible for new work to start before someone has decided, in writing, whether it is in scope. The gate is a delivery process, and it works whatever the contract eventually says.

1. Every request, from any channel, becomes a logged item: email, meeting notes, a support ticket or a comment in a workshop.
2. A named person classifies it against the scope baseline as in scope, change, defect or question, within an agreed response time.
3. Anything classified as change gets an impact estimate: effort, affected components, testing and any effect on dates.
4. Work on a change starts only after the approval your contract requires, and the approval is recorded against the item.
5. The work item cannot enter a sprint or release while it sits in an awaiting-decision state. In Azure DevOps or Jira this is a workflow state and a board rule, not a promise.
6. Small changes are batched into scheduled releases rather than slipped in, so each release has a known scope and a known cost.
7. The log is reviewed with the client regularly, so absorbed changes become visible decisions rather than silent generosity.

The gate protects the relationship as much as the margin, because disagreements are settled one item at a time, while they are small, rather than all at once at renewal.

Which delivery-side levers reduce cost when the contract price does not move?

These change what delivery costs without changing the price. Whether any of them needs a contract variation is for your advisers; the delivery case for each is straightforward.

• Retire customisation the client no longer uses. Less custom code and fewer flows mean less regression testing on every release wave. A technical health check finds what is unused, unsupported or fragile.
• Move to standard platform features where a custom build was done before the feature existed.
• Batch releases on a fixed cadence instead of shipping on request.
• Clarify responsibilities the scope leaves vague, such as who writes test cases, who performs acceptance testing, who handles first-line support and who provides data.
• Define service hours and response targets for support explicitly, so out-of-hours work is a recorded exception rather than the norm.
• Automate deployments and regression tests, so each release costs less senior time.

How does subcontracted senior delivery capacity change the cost side?

It changes the shape of the cost more than the size of any single task. A fixed-price contract delivered from a permanent bench carries salaries between peaks, the cost of hiring when the bench is short, and the rework that comes when the only available person is the wrong level for the work. Subcontracted capacity is paid while the work exists and released when it does not, and senior people tend to need less supervision and less rework on complex Dataverse, plugin, integration and PCF work.

It is not a rescue for every contract. If the price is below the effort the scope genuinely requires when delivered well, a cheaper or more flexible delivery model narrows the loss but does not remove it. A serious subcontractor will also want a clear scope baseline and acceptance criteria before taking on fixed-price work, which is one more reason to finish the reconstruction and the change-control gate first. How white-label delivery is structured, from statements of work to IP and non-solicitation, is set out on our Dynamics 365 subcontracting service page, and why partners use it at all, with the quality controls that protect the prime, is covered in why Microsoft partners subcontract D365 work.

How should new work be scoped so the same losses do not repeat?

Estimate from evidence you produced on this client, not from the original sale.

• Start with a fixed-scope pilot or discovery work package with written acceptance criteria, so the estimate for the larger piece rests on real effort in the real environment.
• Break large work into phases, each with its own scope, acceptance and re-estimation point, rather than one price for the whole.
• Write scope lines at the level of testable outcomes, and list what is explicitly excluded.
• Keep the change-control gate from the first day of the new work, not after the first dispute.
• Record effort against scope lines from the start, so the next reconstruction is a report rather than a project.

Which commercial model the new work should sit under, such as time and materials, capped or phased fixed price, is a commercial decision. The delivery practices above make any of them more predictable.

When does the delivery data suggest a service line cannot be made profitable?

When, after scope discipline is in place, the effort for work that is genuinely in scope still consistently exceeds what the contract pays for, or when the skills the work needs are ones you would have to buy in at a cost the price does not cover. The data can show that pattern clearly. What to do about it, whether to continue, restructure, hand the work to another provider or exit at term, is a commercial and legal decision that belongs to your leadership and advisers, not to a delivery partner.

What delivery can do is make any of those options safer: documented solutions, source in your repository, runbooks and a known issues list, so the client is not harmed whichever way the decision goes. If the platform question is also open for some clients, for example where Microsoft licensing never fitted their size, a custom CRM is one of the routes worth assessing alongside Dynamics 365 and Power Platform.

How does Solzet help Microsoft partners with loss-making legacy delivery?

On the delivery side only. We can reconstruct delivered effort against scope from your time and ticket data, set up a change-control gate in your delivery tools, scope fixed-price pilots and work packages with clear acceptance criteria, and take on Dynamics 365 Customer Engagement and Power Platform delivery white-label under your brand, starting with a fixed-scope pilot. We do not advise on contract renegotiation, legal terms or pricing, and we do not take Dynamics 365 Finance, Supply Chain Management, Business Central or other ERP work. Our senior consultants and full-stack developers bring 8+ years of delivery, working remotely from Yerevan, Armenia, and delivery capacity scales per engagement.