News & Insights
How to Keep Softwares Running With Application Managed Services
Application managed services are what stand between a working business system and the slow decay that ends in an unplanned replacement project. Infrastructure support keeps the servers up. Keeping the software itself running is a separate discipline, with separate skills and a separate contract.
This guide sets out what application managed services cover, the support levels and who owns each one, why business applications degrade even when the infrastructure is healthy, what changes in Malaysia force application work whether you planned it or not, and a scope matrix you can take into a vendor conversation.
What Application Managed Services Cover
Application managed services means a provider taking contracted responsibility for the ongoing operation, support and small-change work of your business applications, against defined service levels.
It sits between two things people confuse it with. An implementation project delivers a system and ends. Infrastructure managed services keep the servers, storage and network available, and stop at the point where the application logic begins. Application managed services own the layer in between: the configuration, the integrations, the data flows, the batch schedules and the code.
A typical scope covers user and functional support, configuration changes, defect fixes, enhancement work within an agreed allowance, vendor patch and release management, integration monitoring, batch and job scheduling, environment management, and the documentation that keeps all of it repeatable.
The 4 Levels of Application Support
Most disputes in application support contracts come from an unclear boundary between levels, or an unclear boundary with the software vendor.
1. Level 1, service desk: Logging, triage and first response. Password and access issues, user error, known workarounds, and routing anything else to the right place. Measured on response time and on how much is resolved without escalation.
2. Level 2, functional and configuration: People who know how your system is configured and how the business uses it. Configuration changes, master data issues, report changes, workflow adjustments, and diagnosis of whether a problem is user error, configuration or a defect.
3. Level 3, technical and code: Developers who can read the code, the interfaces and the database. Defect fixes, integration failures, performance problems, and enhancements. This is the level most internal teams cannot staff for a system they did not build.
4. Vendor escalation: Defects in the packaged product itself, which only the software vendor can fix. Someone must own raising, tracking and chasing these, and the contract should say who, because a vendor ticket with no owner does not move.
Specify at which level each application sits and who covers it. Systems built in-house and heavily customised packages usually need all four; a lightly used cloud product may need only the first and the last.
Why Applications Stop Running Well
The infrastructure can be perfectly healthy while the application deteriorates. Six causes account for most of it.
- Falling out of vendor support. Versions reach end of support on the vendor’s schedule, not yours. Once past it there are no security patches, and the upgrade you deferred becomes an urgent project.
- Integration drift. Applications rarely fail alone. An upstream system changes a field, an API version is retired, or a certificate expires, and the interface fails silently until someone notices missing data.
- Undocumented customisation. Every customisation not written down is a future upgrade blocker. Organisations discover the extent of theirs during the upgrade, which is the worst moment.
- Unmonitored batch and scheduled jobs. Overnight jobs fail quietly. Without alerting on job completion rather than server availability, the first sign is a wrong number in a report days later.
- Configuration drift between environments. When test no longer matches production, testing stops predicting anything, and releases start failing for reasons nobody can reproduce.
- Knowledge held by one person. The single most common cause of a small problem becoming a long outage is that the person who understood the system has left.
Every one of these is a maintenance failure rather than a technology failure, which is precisely what an application managed service is bought to prevent.
What Forces Application Change in Malaysia
Some application work is not optional, and the schedule is set outside your organisation.
Tax and reporting changes are the clearest example. LHDN’s e-Invoice mandate, phased in since 2024 and operating through the MyInvois platform, has required changes to invoicing, master data and integration logic in ERP and billing systems, and continues to require them as guidelines and thresholds are revised. Any application service contract covering finance systems should state explicitly whether regulatory change is in scope or billed as project work, because assumptions differ and the deadline will not.
Financial institutions carry more. Bank Negara Malaysia’s technology requirements cover change management, patching and the recovery of critical application systems, and its business continuity policy requires the disaster recovery plan to be tested for all critical application systems at least annually. That testing obligation reaches the application layer, not just the infrastructure it runs on, so the party who owns the application has to participate.
Personal data adds an obligation that application teams routinely miss. Under the PDPA, personal data does not lose protection when it is copied into a development or test environment. If production data is used for testing, the contract needs to say who may access it, whether it is masked, and how long non-production copies are retained.
Taking an Application Into Managed Support
Transition is where application services succeed or fail, and it is a project with its own plan rather than a start date on a contract.
Documentation baseline. The provider records how the system is configured, which interfaces exist, what the batch schedule does, which customisations are present and what the known issues are. If this cannot be produced, the environment is not yet supportable, and that finding is worth having before the fee starts.
Shadowing, then reverse shadowing. Incoming engineers work alongside the current team, then handle the work while the current team observes. Both phases need to run long enough to include a month-end or a quarter-end, because that is when finance and reporting systems misbehave.
Entry criteria. Agree what must be true before the provider accepts the service: documentation complete, access provisioned, monitoring in place, open defects listed and assigned. Accepting a system that fails these criteria transfers a mess rather than a service.
On pricing, application services are usually quoted per application or per group of applications, with a support fee plus an enhancement allowance expressed in days or points. Check what happens to unused allowance, and what rate applies once it is exhausted.
Application Support Scope Matrix
Take this into the vendor conversation and fill in the last column. Every blank row is a task that will be performed late, twice, or not at all.
| Task | Usually sits with | What to specify in the contract |
| Incident logging and triage | Provider service desk | Response targets by priority, and the hours they apply |
| Configuration and master data changes | Provider, Level 2 | What counts as configuration rather than chargeable change |
| Defect diagnosis and code fixes | Provider, Level 3 | Turnaround by severity, and how regression testing is handled |
| Enhancements and minor change | Provider, within an allowance | The unit of measure, and what happens to unused allowance |
| Vendor patches and version upgrades | Shared with the software vendor | Who tracks end of support dates, and who schedules the upgrade |
| Escalation to the software vendor | Provider, with your entitlement | Whose support contract is used, and who chases the vendor |
| Integration monitoring | Provider | Which interfaces are monitored, and what triggers an alert |
| Batch and scheduled job monitoring | Provider | Alerting on job failure and on late completion, not only on server health |
| Environment management and refresh | Shared | Refresh frequency, and data masking for personal data |
| Release management and testing | Shared | Who tests, who approves, and the rollback plan |
| Documentation and knowledge base | Provider | Delivered to you as an output, and updated with every change |
| Regulatory change work | Negotiable | Whether it is in scope or project work, stated before signing |
| Exit | Both | Documentation handover, code and configuration return, transition assistance |
Where Strateq Fits
Strateq has worked in enterprise IT in Malaysia since 1983, and its enterprise business solutions practice has focused on application platforms since 2012.
The capability that matters for this kind of work is Level 3 depth: people who can read and change the code rather than only restart the service. Strateq’s software engineering practice covers application managed services, application modernisation, enterprise integration, DevOps, DataOps and DevSecOps, and its software engineering work is assessed at CMMI Level 5, which is a verifiable measure of process maturity rather than a claim about effort.
On the application side, the platforms it supports include enterprise business software across ERP, e-Invoice, reconciliation, financials, spend management, robotic process automation and intelligent document processing, along with IT service management and IT operations management tooling. Its public sector delivery includes automating performance reporting for EPF through Datawatch, which is the category of long-running application work this article describes.
Fill in the scope matrix against your own applications, and bring the rows you cannot assign to Strateq’s application managed services team.