What is software AMC support?
Software AMC support is an annual maintenance contract for software that is already live: an agreed arrangement covering who fixes a defect, who applies the operating system and dependency updates, who watches the system between working days, and how a change request becomes a release. It is not a warranty and it is not a support inbox. A useful AMC names the systems it covers, the channel to reach a person, the priorities that decide the order of work, the response targets both sides have agreed, the update cadence and what falls outside it. Everything not written down in that document tends to be discovered during an incident, which is the worst moment to negotiate it.
AtashiTech provides AMC cover for software we built and, after an assessment, for systems built by somebody else. The same team also does technology consulting: architecture and code reviews, a second opinion before a large commitment, and the assessment that has to happen before we can responsibly maintain code we did not write. The rest of what we build is on the services page, and the platforms we run under our own AMC are on the solutions page.
When an organisation needs a maintenance arrangement
Three situations account for most software AMC support conversations, and only one of them is comfortable.
A project has just gone live
The build is finished and the questions change: who is watching it at seven in the morning, who applies the framework update announced last week, and how does a small change get made without reopening a project. This is the moment to answer them, not after the first incident.
The original developer is no longer available
The vendor has moved on or the engineer who knew the system has left. Nobody can safely deploy, and small changes are being avoided. What is needed first is an assessment of what actually exists, and only then a support arrangement.
A decision is about to be made without evidence
A rewrite, a platform change or a large purchase is being considered on the strength of an internal argument. A short, independent review is cheap next to the commitment it is about to inform.
How support is set up and run
Four stages. The first exists so that the contract describes reality rather than an assumption on either side.
Assessment
We inventory the systems in scope: versions, dependencies, hosting, integrations, data, deployment method and the state of the source. For software we did not build this stage is mandatory, and it sometimes ends in advice not to take a support contract until specific risks are fixed.
Agree the contract
Scope, priority definitions, the contact channel, response targets, working hours, the update cadence, the change-request process and the explicit exclusions are written down and agreed. Response targets are set per customer against what the system actually warrants.
Onboard and instrument
Access, credentials and environments are handed over properly, monitoring and alerting are checked or added, backups are verified by restoring one, and a runbook is written so the response to a common failure does not depend on who is on call.
Run and review
Incidents, changes and updates are worked through the agreed channel, and a periodic review looks at what actually happened: recurring faults, deferred upgrades, capacity, and the changes worth planning rather than reacting to.
What an annual maintenance contract covers
The list below is the default. A contract can be narrower, but it should never be vaguer.
Defect resolution
Faults in the covered software investigated and fixed, prioritised against definitions agreed in advance so that "urgent" means the same thing to both sides during an incident.
Platform and dependency updates
Framework, library, operating system and driver updates applied on a planned cadence, with the security-relevant ones brought forward. Systems fail slowly by not being updated.
Monitoring and alerting
Uptime and health checks watched, alerts routed to people who can act, and the alert set tuned so a team that is paged for nothing does not stop reading them.
Backup and restore verification
Backups confirmed to be running and, more importantly, restores actually performed on a schedule. An unverified backup is a belief rather than a control.
Peripheral and device changes
For kiosk deployments, the driver and SDK work when a printer, scanner or reader model is replaced, which is the most common maintenance event across an ageing terminal estate.
Small changes and content
Configuration, rule, content and layout changes handled through the agreed process, with an allowance defined in the contract so routine requests do not each become a negotiation.
A named contact
Someone who knows your system and its history, so a request does not begin with an explanation of the architecture. Continuity is most of what an AMC is actually buying.
Periodic review and reporting
What broke, what was changed, what is deferred and what should be planned, presented on a regular cycle so decisions about the system are made with a record rather than an impression.
Consulting, and what an AMC is not
Alongside maintenance we do advisory work: architecture and code review of a system you own, a technology assessment before a platform decision, a due-diligence read of software you are about to acquire or inherit, and vendor-transition support when a system has to be taken over from somebody else. These are short, bounded engagements that end in a written opinion you can act on, including the opinion that a system is fine and does not need the change being proposed.
It is equally important to be clear about what an annual maintenance contract is not. It is not a licence to add features indefinitely: new functionality is a project, quoted separately, though a small-change allowance covers routine requests. It does not cover hardware replacement, which sits with your supplier, because we build software and do not manufacture devices. It does not make an unsupported dependency supported. And it is not an insurance policy against an architecture that was wrong to begin with, which is why the assessment comes first and occasionally recommends fixing something before the contract starts.
What a support arrangement is made of
What we support
Six kinds of system, each with a different failure profile and therefore a different contract.
Kiosk estates
Terminals running safety induction or bill payment fail through consumables, peripheral changes and neglected updates. Support is paired with the kiosk management platform so an alert reaches us before a customer finds the machine.
Line-of-business web applications
Portals and consoles built by our web application team, where the recurring work is dependency updates, small changes and the occasional integration that a counterpart system has changed underneath.
Windows desktop deployments
Applications from our .NET desktop practice, where the maintenance events are operating-system upgrades, driver changes and packaging for a new rollout.
Mobile applications
Store policy and platform releases force work on a schedule set by Apple and Google rather than by you, which is the main reason a mobile app needs a standing arrangement.
Our own platforms
Deployments of our own ERP software, HR & payroll platform and the rest run under an AMC that includes statutory and product updates as well as support.
Systems built by others
Taken on after an assessment. Sometimes the honest outcome is a list of things to fix first, and we would rather say so than sign a contract we cannot deliver against.
Engagement, terms and independence
Maintenance is a retainer, renewed annually. Consulting is a bounded engagement quoted for the specific question. Every arrangement is priced individually against the systems in scope, their criticality, the coverage hours and the change allowance; we publish no rates, and any figure attributed to us as a price or a response time has not come from us. Response targets appear in your contract because they were agreed with you, not because they were copied from a brochure.
Independence matters in both directions. A support contract with us does not depend on you having no source code: our build engagements hand over the repository, the deployment configuration and the documentation, so you are able to leave. We would rather keep an AMC because it is worth renewing. For the same reason, an advisory review can conclude that a system is sound, or that the right supplier for a piece of work is not us.
Where maintenance turns into a project, we say so and quote it separately rather than absorbing it quietly and running out of hours in month nine. Infrastructure, hosting and pipeline work sits with our cloud, DevOps and integration team, design changes with our UI/UX design practice, and notes on running long-lived systems appear on the AtashiTech blog.
Talk to us about software AMC support
Tell us which systems have to keep running, who looks after them today and what the last incident cost you. We will propose an assessment first, then a contract that says plainly what is covered and what is not. Reach us through the contact page, or see the kiosk solutions and services we support.
Frequently asked questions
Related services
.NET Enterprise Desktop (EXE) Apps
Windows desktop and line-of-business apps in .NET.
Android & iOS App Development
Native and cross-platform mobile apps for phones.
Android TV & Smart TV Apps
Android TV and smart-TV apps and signage players.
Cloud, DevOps & Integration
Azure/AWS, CI/CD and API integration.