Application Managed Services for Custom Microsoft Applications

Application Managed Services for Custom Microsoft Applications: Who Runs What Was Built

The application went live. The partner that built it rolled off at acceptance, the handover was a documentation drop and a two-hour walkthrough, and for several months nothing went wrong. Then the first real release wave landed, a connector changed behavior, and someone had to decide whether that was a bug, a platform change or a design assumption that had quietly expired. That is the week a team discovers that “supported” and “owned” are different words, and that nobody wrote down which one applied here.

Your decision is not whether the application needs an owner. It does. The decision is which of four sourcing models should hold that role, and what the agreement for it has to say.

Quick Answer

Application managed services (AMS) means running, supporting and enhancing one named application under a defined scope, with one provider accountable for it. For a custom Microsoft application, buy AMS when the application is business-critical, changes with every platform release wave, and your team lacks depth in its stack; keep it in-house when it is stable and your team owns the platform; use staff augmentation when the gap is capacity, not knowledge; use an MSP only for the estate around it, never for the application itself. An AMS agreement runs the application. It never runs your tenant, your infrastructure or your help desk, and it ends with your code, environments and documentation in your hands.

What Application Managed Services Covers, and What It Never Should

The term is doing a lot of work, and it is worth being precise, because the same two words are used to sell an application engagement and an estate engagement. Those are different purchases with different risks.

Scoped to an application, AMS covers five things:

1. Operate. Running the application and its workflows day to day: monitoring that they are executing, that scheduled jobs complete, that integrations are still connected, and that failures surface to a named owner instead of a shared mailbox.
2. Support. Diagnosing and resolving defects in the application itself, including the ones that turn out to be a changed dependency, not a code fault.
3. Patch for release waves. The Microsoft platform moves on a published cadence. Somebody has to regression-test the application against each wave, decide what breaks, and fix it before your users find it.
4. Enhance. Absorbing the change requests that accumulate after go-live, under a defined allocation, not an open-ended promise.
5. Document. Keeping runbooks, environment records and architecture decisions current, so the knowledge does not live in one person’s head.

What it should never cover, and the boundary matters more than the list:

• Your tenant. Identity, licensing, conditional access and tenant-level configuration are estate concerns, not application concerns.
• Your infrastructure. Networking, endpoints, servers.
• Backup and disaster recovery, as an estate service.
• Security operations. A SOC or MSSP function.
• Your help desk. Password resets, break-fix, general end-user support.

If a proposal called “application managed services” includes those five, you are not being sold application managed services. You are being sold a managed IT contract with an application attached to it, and the price, the term and the exit will all be shaped by the larger thing, not the smaller one.

This is a real line and we hold it on our own site. Our position on general managed IT is set out plainly on We Do Not Run Your Help Desk. Here Is What i3solutions Does Instead., and that position has not changed. Application managed services is application-scoped: it covers a named application and its workflows, never the estate that surrounds them. If your problem is the estate, the answer on that page is still the right answer.

AMS, In-House, Staff Augmentation or an MSP: The Decision Criteria

You are choosing between four models, and the honest position is that all four are correct in some circumstance. The question is which circumstance you are in. Work down the criteria. The rows are not weighted equally: criticality and exit posture decide the close calls, and the model that wins those two is the answer.

Two distinctions carry the decision.

Capacity versus knowledge. This is the cleanest test between staff augmentation and AMS. If you know exactly what needs doing and simply do not have the hours, you need hands, and staff augmentation is cheaper and more flexible. If you do not know what needs doing, because the application’s design decisions live with someone who has left, then adding hours to the team does not help. You need the expertise, and you need it accountable for an outcome, not for a timesheet. The hourly-versus-retainer shape of that choice is covered in more depth on staff augmentation: hourly versus retainer.

Application versus estate. If the trouble is that nobody patches the servers, nobody answers the phone and nobody owns the backup, that is an estate problem, and an application contract will not fix it. The reverse is also true and is the more expensive mistake: buying an estate-wide managed contract to solve a single application’s ownership gap means paying for a help desk you did not want and handing over a tenant you never meant to transfer. Where the boundary between application work and estate operations sits in a regulated environment is set out on governed Microsoft 365 support for a regulated estate.

If the model is right but you are still deciding what kind of firm should hold it, the trade-offs between a boutique and a global firm are covered on boutique versus global consulting firm.

What an AMS Agreement for a Custom Microsoft Application Must Contain

The scope document, not the delivery, is where an AMS engagement goes wrong: it never said what was included, and the argument surfaces the first time something expensive breaks. The clauses below decide whether the agreement works, described in the order they tend to cause trouble.

A named application inventory. Not “the Power Platform environment” but the specific applications, flows, connectors and integrations under the agreement, listed. Anything not on the list is not covered, and both sides should want that written down.

Environment ownership. Which of development, test and production the provider operates, which you retain, and who may deploy to each. Ambiguity here is how a change nobody authorized reaches production.

Release-wave regression responsibility. The platform will change on a published cadence whether or not the contract mentions it. State who tests the application against each wave, who decides what constitutes a break, and who fixes it. If this clause is absent, the answer in practice is that nobody does it until a user reports it.

Enhancement capacity as a defined allocation. Enhancement work should be a bounded, named allocation, with a stated rule for what happens to unused capacity and what happens when a request exceeds it. Open-ended enhancement promises are how an application agreement quietly becomes an evergreen retainer.

Documentation and runbook ownership. Who maintains the runbooks, where they live, in whose tenant, and in what state they are handed back. Documentation that lives only with the provider is a lock-in mechanism whether or not anyone intended it that way.

Security-patch responsibility, split explicitly. Application-layer patching sits with the application provider; platform, identity and tenant patching sits with whoever runs your estate. Write the split down, because the gap between the two is exactly where an audit finding lands.

Knowledge-retention clauses. Named people, and an obligation that what they learn is written down, not merely accumulated. The value of the builder-as-provider argument depends entirely on this clause being real.

Exit terms. Code, environments and documentation return to you, in a usable state, on a defined trigger. No lock-in. A provider who resists this clause has answered the lock-in question for you.

One thing deliberately absent from this list: service levels. Response times, uptime commitments and support-hour windows are real parts of a support agreement, but they belong to the support model rather than to the sourcing decision, and they are shaped by the application and the environment rather than by a standard table. The model and what shapes it are covered on Post-Implementation Support Services: Operational Excellence After Deployment.

Why the Builder Is Usually the Right AMS Provider, and When It Is Not

When the team that built an application rolls off, or its contract ends, the cost lands on you: the reasons behind each design decision, why a particular integration works the way it does, and the failure modes found during testing all leave with that team, and a new provider rebuilds that understanding at your expense. It discovers the same things in the same order, because it learns the application the way the builder did, through the failures the application produces in use. That is the builder’s argument for running what it built, and it is a strong argument.

There are two honest arguments against, and both have contractual answers, not rhetorical ones. The decision rule: the argument about being locked in wins when the provider will not sign exit terms that return code, environments and documentation to you; the roadmap argument wins when you already plan to replace or retire the application before the agreement would end; when neither holds, the builder’s knowledge wins.

Lock-in. If the only people who understand the application work for the provider, switching becomes theoretical. This is answered by the exit terms and the documentation clause, not by assurances. If code, environments and documentation return to you on demand, the lock-in argument weakens considerably. If they do not, it is correct, and no amount of goodwill fixes it.

Roadmap divergence. A builder has an interest in the application continuing to exist in roughly its current shape. Your business may need it replaced, absorbed into a platform capability, or retired. A provider who cannot say “this should be retired” is not giving you advice. Test this before signing by asking what would have to be true for them to recommend ending the engagement.

What this agreement is not: An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in. The word “managed” carries freight it should not. An application managed services agreement is a scoped agreement to run a named thing well. It is not a transfer of your IT function, and it should not be structured as one.

How i3solutions Scopes Application Managed Services

We provide application managed services scoped to the applications and workflows we built or modernized: their operation, support and enhancement. General managed IT operations and help desk are out of scope and remain so.

That scope is deliberate rather than modest. The argument for the builder as the provider rests on knowledge that carries over from the build, and it only holds where that knowledge exists.

i3solutions designs Azure integration architecture and builds and operates Azure Logic Apps workflows for enterprise clients, including running them on an ongoing basis rather than only building them.

If the application we built is stable and your team has the depth to run it, we will say so.

Where you need the support model itself defined, including how it is structured and what shapes it, that is set out on Post-Implementation Support Services: Operational Excellence After Deployment. Where the question is whether to build or configure in the first place, that sits with Custom Application Development Services for Enterprise Performance.

Honest Counter-Case: When You Should Not Buy Application Managed Services

Four situations where the answer is no, and it is worth checking yourself against them before you run a procurement.

The application is stable and your team owns the platform. If it changes rarely, survives release waves without intervention, and more than one person on your team understands it, an AMS agreement buys insurance against a risk you have already mitigated. Keep it, and revisit if the team changes.

You are retiring or replacing the application inside your planning horizon. If a replacement is already on your roadmap, an operating agreement that outlasts the outgoing system is money spent on something you are deliberately ending. Scope a maintenance floor instead: keep it running and secure, and stop enhancing it.

The gap is capacity, not knowledge. If your team knows precisely what needs to happen and simply cannot get to it, you need hours, not accountability for an outcome. Staff augmentation is the cheaper and more flexible answer, and converting a capacity problem into a managed agreement buys accountability you do not need.

It is an estate problem wearing an application costume. If the real issue is that nobody patches, nobody monitors and nobody answers the phone, then the application is a symptom. An application-scoped agreement will not fix it, and buying one will leave you with the original problem plus a contract.

Key Takeaways

• Application managed services runs, supports and enhances one specific application under a defined scope. It is not managed IT, and it is not a help desk.
• The clearest test between AMS and staff augmentation is capacity versus knowledge. Hours are one problem; expertise is another.
• The clearest test between AMS and an MSP is application versus estate. Buying the larger contract to solve the smaller problem is the expensive mistake.
• The agreement is where these engagements succeed or fail. Insist on a named application inventory, environment ownership, release-wave regression responsibility, a bounded enhancement allocation, documentation ownership, an explicit security-patch split, knowledge retention and exit terms.
• The builder is usually the right provider because of knowledge carried over from the build, but only if the exit terms make leaving genuinely possible.
• If the application is stable, being retired, or short of hours rather than expertise, do not buy it.

What is left is the case this page was written for: a custom application or workflow i3solutions built or modernized, a team deciding who should run it, and an agreement that has not been written yet. Bring the application inventory as you understand it, the release-wave history since go-live, and the names of the people who currently answer when it breaks. Talk to a senior architect