Why your AMS costs 10× too much

AMS was born in the 1990s, when maintaining an ERP system physically required on-site experts able to navigate complex proprietary interfaces, modify programs in COBOL or ABAP, and manage critical on-premise infrastructure. The time-and-materials billing model was then the only reasonable option: complexity was real, unpredictable, and difficult to standardize.

Thirty years later, D365 Finance & Operations runs on Azure, has exhaustive documentation, a standardized API, and a language (X++) whose patterns are well documented. The tools have changed radically. But the AMS economic model has remained identical: monthly retainer + daily rates for developments. This inertia is not accidental — it is profitable for providers.

The paradox is striking: on one side, Microsoft invests billions to make D365 more standardized, more documented, easier to maintain. On the other, AMS costs have not decreased — they have often increased, as providers consolidated their position and the scarcity of D365 experts kept rates rising.

Mechanism 1: over-staffing. Your AMS contract often includes more FTEs than necessary, 'to handle peak loads'. In practice, these resources are partially deployed on other clients during slow periods. You pay for availability you do not fully use.

Mechanism 2: voluntary complexity. An AMS provider that simplifies and automates its own work reduces future billable hours. There is therefore no incentive to optimize, document, or set up tools that would make maintenance less costly. Some providers actively discourage internal teams from building competence — thereby preserving their role as an indispensable intermediary.

Mechanism 3: documentary lock-in. By not properly documenting customizations, not structuring code repositories, not training your internal teams, the AMS provider creates structural dependency. Changing providers becomes so costly (knowledge migration, operational risk) that it is often easier to accept the annual rate increase.

Mechanism 4: billing for re-opened tickets. When a fix introduces a new bug (regression), the ticket is re-opened and re-billed. In a model where quality is not contractually guaranteed, regressions are an additional revenue source for the provider.

AI suffers from none of the four mechanisms described above. It is not over-staffed (it scales on demand), it has no incentive to complexify (its marginal cost is near zero), it automatically documents everything it produces, and it has no interest in introducing regressions (it is paid per result, not per hour).

But the deepest change is in the risk model. With SKALP AI, you pay €200 per resolved ticket. If the ticket is not satisfactorily resolved, it is not billed. This model perfectly aligns interests: SKALP AI is only profitable if you get results. This is the exact antithesis of the AMS model.

Furthermore, each ticket generated by SKALP AI is documented, tested, and versioned in Azure DevOps. There is no documentary lock-in — on the contrary, the knowledge base of your D365 is enriched with every resolved ticket. After 12 months of use, you have comprehensive documentation of all your customizations, generated automatically. This is a governance asset that few organizations possess today.

Migrating from AMS to SKALP AI is not a big-bang change. It can be done progressively, over 3 to 6 months, without service disruption. Step 1: identify the 20% most common ticket types in your backlog — typically reports, simple automations, form modifications. Test SKALP AI on these tickets for 2 to 3 months in parallel with your existing AMS. Measure the results (lead time, quality, cost).

Step 2: expand the scope to medium-complexity development tickets. Simultaneously reduce your AMS FTE volume accordingly. Most AMS contracts allow this modulation if you respect the contractual notice periods. Step 3: renegotiate your residual AMS contract to focus it on very high-value activities (architecture, production crises, critical legacy integrations) where human expertise remains indispensable.

Following this migration, most CIOs we support reduce their AMS bill by 60 to 75% while increasing the number of tickets resolved per month. The backlog shrinks, user satisfaction improves, and the CIO regains control of their application portfolio. That is the true benefit of the AI transition — not just the cost, but the posture.