>
Contact Let's Talk
Home › Services › Managed Services

Managed IT services company for application managed services

MJC GlobalTech is a managed IT services company that runs enterprise applications after go-live — application managed services for SAP ECC and S/4HANA, Oracle Fusion and E-Business Suite, Microsoft Dynamics 365, Salesforce, ServiceNow and Workday, plus the AWS, Azure and OCI estates underneath them. The word "managed" is used loosely in this market, so this page sets out exactly what we mean by it: which tier resolves which class of ticket, how the transition is proven before we take accountability, how the service level is written so it can be met honestly, and how you leave if you want to.

L1–L3
Tiers staffed in one team
3
Shift model options: single, extended, follow-the-sun
CMMI 3
Appraised delivery organisation
ISO 27001
Certified information security

What should be written into an AMS contract

  • Severity definitions with a named arbiter when you and we disagree on P1
  • Response targets separated from resolution targets, with vendor-dependent tickets carved out
  • A funded enhancement allowance, expressed in hours or points per month
  • The shift model stated plainly: three shifts, extended cover, or India hours plus on-call
  • Runbook and configuration documentation as a deliverable, not a courtesy
  • A transfer-out clause with a defined notice period and handover artefacts
Why AMS engagements disappoint

Most support contracts fail on definitions, not on effort

Very few application managed services engagements go wrong because the engineers were poor. They go wrong because two parties signed a document that described the same words differently. The buyer read "24/7 support" as three staffed shifts; the provider costed one India shift with a pager after hours. The buyer read "L3 support" as someone who can read ABAP or an Apex trigger; the provider costed a tier that raises an OSS note and waits. The buyer assumed small improvements were part of the service; the provider assumed every change order was billable. None of this is discovered at signature. It is discovered at the first month-end close that breaks.

The commercial signal is worth learning to read. When several AMS quotes land and one is markedly cheaper, it is almost never a better rate card — it is a different tier mix. A provider can hold price down by staffing heavily at L1, resolving against a known-error database, and routing anything that needs configuration or code to your retained team or to a change request. That is a legitimate service and sometimes the right buy. It is only a problem when it is sold as full application maintenance and support.

We would rather have the awkward conversation during scoping. That means telling you where an SLA cannot honestly be promised — a defect that sits in vendor code, for instance, has a response time we control and a resolution time we do not. It means being explicit that a single-shift model with on-call is a cheaper product than follow-the-sun, and pricing it as such rather than letting the phrase "round the clock" do the work.

Tier inflationEverything is called L3 until a ticket needs a code fix.
Resolution SLAs on vendor defectsPromising a clock the provider does not own.
Improvement ambiguityEvery small enhancement reopens a commercial negotiation.
Undocumented takeoverSupport built on documentation rather than on what is running.
What the service covers

Application managed services, described tier by tier

Our practitioners hold genuine vendor certifications on the platforms below. We are an independent services organisation and make no claim to vendor partner-programme status.

L1 L2 L3 support: what each tier is actually allowed to do

The tier boundary decides your cost and your resolution profile, so we define it by action, not by seniority. Getting this written down is the single most useful hour of a scoping call.

  • L1 — intake, triage, severity assignment, user guidance and resolution of known errors against a maintained runbook; no configuration change
  • L2 — functional and configuration work inside the application: pricing procedures, workflow and approval routing, integration monitoring, master-data and authorisation fixes
  • L3 — code and root cause: ABAP or CDS objects, Oracle PL/SQL and personalisations, Apex and flows, plus formal escalation into the vendor and management of the note or patch that follows
  • A retained-organisation column, so the tickets your own team keeps are named rather than assumed

Transition and application health check before we take accountability

Taking over a system you did not build is where AMS succeeds or fails. We refuse to support against a design document; we support against what is actually running in production today.

  • A health check that records live configuration, custom objects, interface inventory and job schedules — not the as-built document, the current state
  • Technical debt logged openly: unsupported customisations, modifications that will block the next upgrade, interfaces with no error handling
  • Shadow period — our engineers watch your team work the queue and write the runbook as they go
  • Reverse shadow, then solo operation with an agreed go or no-go gate before the SLA clock starts

SLA design that can be met honestly

Percentages are the least interesting part of a service level. Severity definitions and the arbitration route are what you will actually argue about in month four.

  • Response time and resolution time kept as separate commitments, because they are separate things
  • Severity written against business impact — a stalled month-end close or a blocked outbound delivery — rather than against the number of users affected
  • A named arbiter and an escalation path for when the business calls it P1 and we do not
  • Vendor-dependent tickets excluded from resolution clocks and reported separately, with the vendor reference visible to you

24/7 IT support: follow-the-sun versus on-call

True round-the-clock support means either three staffed shifts or a genuine handover model between locations. Anything else is on-call, which is a different and cheaper service.

  • Follow-the-sun — staffed shifts with a structured handover: open P1s, watch items and the state of overnight batch passed person to person, not left in a mailbox
  • Extended cover — a long day shift that overlaps your business hours across time zones
  • Single shift plus on-call — India hours staffed, defined out-of-hours rota for severity one only
  • Whichever you choose is stated in the contract in these words, with the roster visible to you

ERP managed services and the enhancement backlog

The difference between a support contract and a partnership is whether improvement is funded inside the service. Most AMS dissatisfaction traces back to this one ambiguity.

  • A monthly enhancement allowance inside the fee, sized in hours or points and drawn down against a backlog you prioritise
  • A clear threshold above which work becomes a project — and the threshold is a number, not a judgement
  • Unused allowance treated per an agreed rule, so nobody games the month end
  • Backlog grooming in the service review, with your product owner ranking items, not us

Beyond tickets: release, environment and patch management

A queue-only service leaves the riskiest work unowned. Managed should include the operational cycles that keep the platform supportable rather than merely available.

  • Release and transport management, including regression scope and the promotion path across development, quality and production
  • Environment and client refresh cycles, with data scrambling where personal data is involved
  • Vendor patch and support-pack cadence, and the upgrade runway for platform releases
  • Capacity and cloud cost review on AWS, Azure or OCI — licence, instance sizing and storage growth looked at on a schedule

NOC services and alerting that reaches a named person

Monitoring is only worth its licence cost if an alert ends up with somebody accountable. We design the alert-to-owner path before we turn the dashboards on.

  • Interface and batch monitoring with thresholds set per job, not one global rule
  • Alert routing to a roster position with an acknowledgement requirement and an unacknowledged escalation after a fixed interval
  • Noise reduction as a standing task — an alert nobody acts on is deleted or retuned, not muted
  • Problem management that closes the loop: recurring incidents become a permanent fix or a documented known error

Exit, transfer and documentation you own

A service you cannot leave is a trap. Exit terms belong in the original contract, when you still have negotiating position, rather than in the argument that prompts them.

  • Runbooks, known-error database and configuration documentation contractually yours and kept current, not assembled at the end
  • A defined reverse-transition path: knowledge transfer to your team or to an incoming provider
  • Notice period, handover duration and the artefact list agreed at signature
  • No dependence on individual tribal knowledge — named backups for every process area
Choosing a model

In-house team, AMS, managed pod or build-operate-transfer

In-house teamClassic AMSManaged podBuild-operate-transfer
Who is accountableYou, end to endProvider, against SLA per ticketProvider, against outcomes and backlog throughputProvider during build and operate; you after transfer
Cost profileFixed salary base, expensive at low volumePer-ticket or fixed monthly fee, scales down wellFixed pod cost, predictable, less elasticHighest during overlap, lowest once transferred
Speed to capabilitySlow — hiring plus platform ramp-upFastest — transition measured in weeksFast, with a short forming periodSlowest overall, deliberately
Knowledge retentionStays with you, at attrition riskSits with the provider; depends on runbook disciplineStrong, because the pod is stable and namedDesigned to end up with you
Best whenThe platform is core differentiation and volume is highSteady-state system, predictable ticket mix, cost pressureSupport and enhancement run together on one roadmapYou want a captive capability later but cannot hire now

Most enterprises end up with a blend: classic AMS on the stable back office, a managed pod on the platform still changing, and a small retained team holding architecture and vendor relationships. The mistake is buying one model for everything.

How we deliver

Transition: shadow, reverse shadow, solo

We do not start an SLA on day one. Accountability transfers when the team has demonstrably worked your queue, and the gate is documented.

01

Health check

Two to four weeks inspecting the running system: configuration as deployed, custom object inventory, interface map, job schedule, open backlog and the last twelve months of incident history. The output is a findings register including technical debt you may not have been told about.

02

Scope and tier mapping

Every recurring ticket type placed at L1, L2, L3 or retained. Severity definitions agreed and the arbitration route named. Shift model chosen explicitly. Enhancement allowance sized.

03

Shadow

Our engineers sit behind your incumbent team or internal staff, taking no accountability, and write the runbook and known-error entries from live tickets rather than from documentation.

04

Reverse shadow

We work the queue; the outgoing team reviews. Gaps in the runbook surface here, which is the point of the phase. Exit criteria are agreed in advance and measured.

05

Hypercare and cutover to SLA

A defined hypercare window at heightened attention, then a formal go or no-go decision. The service level starts when the gate is passed, not when the contract was signed.

06

Steady state and service review

Monthly review covering severity distribution, breach analysis with causes, problem-management progress, enhancement burn-down, patch and upgrade runway, and cloud cost trend. Backlog re-prioritised by your owner.

07

Exit readiness, maintained

Runbooks and documentation kept current as a standing service obligation, so a reverse transition is a scheduled activity rather than a reconstruction project.

Related

Platforms and related services

SAP servicesECC and S/4HANA work, including AMS on both. Oracle servicesFusion applications and E-Business Suite support. Microsoft servicesDynamics 365 and the Azure platform beneath it. ServiceNowThe ITSM platform our service desk runs on. Cloud and infrastructureAWS, Azure and OCI estates under managed cover. Global capability centresWhen build-operate-transfer fits better than AMS. Workforce managed servicesManaged delivery for people-heavy scope. Scope an AMS engagementStart with a health check, not a proposal.
Questions we get

Application managed services: the questions buyers should ask

What is the real difference between L1, L2 and L3 support?
L1 triages, assigns severity, guides users and closes known errors against a runbook, without changing configuration. L2 works inside the application: configuration, workflow and approval routing, integration monitoring, master data and authorisations. L3 touches code and root cause — ABAP, PL/SQL, Apex — and owns escalation into the vendor. A quote that looks unusually cheap is usually L1-heavy, with configuration and code work excluded or billable separately.
Why does an AMS provider insist on a health check before quoting?
Because supporting a system you did not build against its documentation is guesswork. A health check records configuration as actually deployed, the custom object and interface inventory, the job schedule and the incident history. It also surfaces technical debt — unsupported modifications, interfaces without error handling — that changes the effort estimate materially. A provider quoting without one is either guessing or planning to reprice later.
Should an AMS contract include resolution-time SLAs?
For issues we can resolve, yes. For defects sitting in vendor code, a resolution clock is dishonest: we control how fast the note or case is raised and chased, not when the vendor ships a fix. Those tickets should be carved out of resolution SLAs and reported separately with the vendor reference visible. Severity definitions and the arbitration route matter more than the percentage targets anyway.
What counts as genuine 24/7 IT support?
Either three staffed shifts, or a follow-the-sun model with a structured handover where open priority-one incidents, watch items and overnight batch state pass person to person. A single India shift with an out-of-hours rota is a different product: cheaper, appropriate for many systems, and it should be sold in those words. Ask which of the three you are buying and have the answer written into the contract.
Is enhancement work included in ERP managed services, or billed as projects?
This ambiguity causes more AMS dissatisfaction than SLA breaches do. We include a monthly enhancement allowance in the fee, sized in hours or points, drawn down against a backlog your product owner prioritises, with a stated numeric threshold above which work becomes a project. Without a funded allowance and a defined threshold, every small improvement reopens a commercial negotiation.
How long does transition take, and when does the SLA start?
As a planning figure, a mid-size single-platform estate typically runs eight to twelve weeks from health check to solo operation; a multi-platform landscape with heavy custom code runs longer. The sequence is health check, tier mapping, shadow, reverse shadow, hypercare. The SLA starts when the reverse-shadow exit criteria are met and a go decision is recorded — not on the contract date.
What should managed services cover beyond the ticket queue?
Release and transport management with a defined promotion path, environment and client refresh cycles, vendor patch and support-pack cadence with an upgrade runway, monitoring and alerting that routes to a named roster position with acknowledgement and escalation, problem management that converts recurring incidents into permanent fixes, and periodic capacity and cloud cost review. A queue-only service leaves the riskiest work unowned.
How do we get out of an AMS contract without losing the knowledge?
Negotiate exit at signature, while you still have position. Runbooks, the known-error database and configuration documentation should be contractually yours and kept current as a standing service obligation. The contract should name the notice period, the reverse-transition duration, the handover artefact list and named backups per process area, so no single engineer holds the estate in their head.

Let's build what's next — together.

Whether it's setting up your India GCC, modernizing your enterprise stack, or hiring 50 engineers in 30 days — we'd love to scope it with you.

Schedule a Call → Email Business Team