An AMS handover is only finished when every recurring job your custom system needs has a named bucket: warranty, AMS run, AMS change pool, or kept by you. Most post-go-live arguments in Singapore mid-market programmes are not about SLA clocks. They come from work nobody scoped: certificate renewals, runtime upgrades, access reviews, restore tests, partner API changes. This AMS scope checklist lists those jobs, who should own each one, and what to write into the AMS schedule before the build team rolls off.
Educational only; not legal advice. Have your counsel review contract wording. The worked example below is constructed for illustration and is not a client case or a benchmark.
Who this is for, and who should skip it
For: the person who inherits a custom system after go-live at a Singapore mid-market company: a head of IT, an operations director, a product owner or a finance lead who signs the support contract. A build vendor is finishing warranty, an application management (AMS) provider or an internal team taking over, and a nagging feeling that some work will fall through the gap.
Skip if: you need the transition mechanics (artefacts, shadow and reverse-shadow weeks), which the AMS handover runbook covers; you are negotiating response and restore clocks, which belong in the AMS SLA negotiation guide; or you are still deciding when hypercare ends, which the hypercare exit criteria checklist handles. This article does one job: make sure the AMS scope has no orphaned work.
Scope, not SLA, is where AMS goes wrong
An SLA tells you how fast someone responds when something breaks. Scope tells you whether anyone owns the quiet jobs that stop things breaking. A system can meet every SLA for six months and still go dark because a TLS certificate expired or a payment gateway retired the API version your integration calls. Nobody missed an SLA; the job belonged to no one.
The fix is boring and effective: list every recurring job, assign each to one of four buckets, and attach the list to the AMS schedule as a signed appendix.
The four buckets
| Bucket | The test | Who usually pays | Typical examples |
|---|---|---|---|
| Warranty | The system does not do what the accepted specification said, and the defect was reported inside the warranty window | Build vendor, under the warranty clause | A calculation that is wrong against signed-off test cases; a screen that fails on a supported browser |
| AMS run | Keeps the current system working without changing what it does | Fixed monthly AMS fee | Monitoring, patching, certificate renewal, backup checks, user support, incident fixes after warranty |
| AMS change pool | Changes what the system does, however small | A pre-agreed pool of hours or points, drawn down by approved tickets | New report column, extra approval step, new partner field, runtime major-version upgrade |
| Kept by you | A business decision, a contract, or an account that must stay in your company’s name | You, directly | Domain and DNS registrar, cloud billing root account, app-store developer accounts, PDPA accountability, third-party contracts |
For how to word the warranty bucket so it ends cleanly, see the guide on Singapore software warranty and defect liability clauses.
The orphaned-jobs register
This register lists jobs that commonly slip between warranty, AMS and the buyer. Copy it into your tracker, add a named owner per row, and do not sign the AMS schedule until every row has a bucket.
| # | Recurring job | Why it gets orphaned | Suggested bucket | Evidence it is working |
|---|---|---|---|---|
| 1 | TLS certificate renewal and automation | Set up once by the build team, renewed by whoever notices | AMS run | Expiry dashboard; automated renewal log |
| 2 | Runtime and framework upgrades (minor/patch) | Seen as “not broken” | AMS run | Monthly dependency report with versions |
| 3 | Runtime major-version upgrades | Too big for run, too dull for the roadmap | AMS change pool, planned yearly | Upgrade on the 12-month calendar with a target quarter |
| 4 | Security patching of OS, containers and libraries | Split across cloud, AMS and internal IT | AMS run, with a patch window in the schedule | Patch log; vulnerability scan trend |
| 5 | Backup restore tests | Backups run, nobody restores | AMS run | Quarterly restore record with time taken |
| 6 | Privileged access reviews | Project accounts outlive the project | AMS run executes; you approve | Signed quarterly access list |
| 7 | Partner API version changes (payment, logistics, messaging) | Notice emails go to a departed project lead | AMS run to monitor; change pool to implement | Deprecation watchlist with dates |
| 8 | Third-party API keys and secrets rotation | Keys created on a developer’s account | AMS run; keys held in your vault | Rotation dates in the secrets register |
| 9 | Scheduled jobs and batch reconciliation | Fail silently at night | AMS run | Job-failure alerts routed to the AMS queue, not a personal inbox |
| 10 | Data fixes requested by the business | Treated as favours, never counted | AMS run if rare; change pool for an admin tool if frequent | Monthly count of data-fix tickets |
| 11 | Data retention purges and archiving | Built as a feature, never scheduled | AMS run executes; you set the rules | Purge job log against your retention schedule |
| 12 | Cloud cost review and rightsizing | Billing sits with finance, resources with engineers | Kept by you, with AMS input; see FinOps for Singapore teams | Monthly cost note with top three changes |
| 13 | Domain, DNS and app-store account renewals | Registered on a vendor card or personal email | Kept by you | Accounts in company name; renewal dates on the calendar |
| 14 | Breach-notification chain with the AMS provider | Assumed to be “in the DPA somewhere” | Kept by you; AMS duty written in | Named contacts and a tested call tree |
| 15 | Disaster recovery rehearsal | Expensive, so postponed | AMS change pool or a separate annual line | Annual DR test report |
Add jobs specific to your system, such as payroll cut-off runs, month-end reports or regulatory submissions. What matters is that each row has one owner.
Three jobs with external clocks you cannot negotiate
Some rows on the register run on someone else’s calendar. They deserve explicit lines in the AMS schedule.
Certificate lifetimes are shrinking
Under the CA/Browser Forum Baseline Requirements, the maximum validity of publicly trusted TLS certificates dropped to 200 days for certificates issued from 15 March 2026, falls to 100 days from 15 March 2027, and to 47 days from 15 March 2029. A certificate renewed by hand once a year is already off the table. Write automated renewal and expiry monitoring into AMS run, and ask the provider to show you the renewal log, not just promise it.
Runtimes have published end-of-life dates
Most runtimes and frameworks publish support windows. Node.js, as one example, states on its release page that LTS releases typically get critical bug fixes for a total of 30 months and that production applications should only use Active LTS or Maintenance LTS releases. Whatever your stack, list each runtime with its end-of-support date and put the major upgrade in the change pool with a target quarter, well before that date.
PDPA breach notification needs your AMS provider in the chain
If your AMS provider handles personal data on your behalf, it is likely acting as a data intermediary. Under section 4(3) of the Personal Data Protection Act 2012, your organisation has the same obligation for that data as if it processed the data itself. Section 26C(3) requires a data intermediary that has reason to believe a breach occurred to notify you without undue delay, and you must then assess whether it is notifiable. Once you assess that it is, section 26D requires you to notify the Commission no later than 3 calendar days after that assessment. Your AMS schedule should name who the provider calls, by when, and with what information. Test the call tree once a year.
Illustrative worked example: reading hypercare tickets before you sign
Constructed for illustration; numbers are made up to show the method.
A Singapore distributor goes live with a custom order-and-delivery portal. Hypercare runs six weeks and logs 120 tickets. Before signing the AMS schedule, the product owner sorts them into the four buckets:
| Ticket type | Count | Bucket | What it tells you |
|---|---|---|---|
| Defects against accepted test cases | 38 | Warranty | Build vendor fixes; track closure before warranty ends |
| How-to and user errors | 27 | AMS run | Training gap; a short user guide may cut these more than any SLA |
| Manual data fixes | 22 | AMS run, for now | Too many: a small admin screen in the change pool would remove most of them |
| Enhancement requests | 18 | AMS change pool | Real demand; needs a monthly prioritisation meeting |
| Access and configuration | 15 | AMS run; approvals kept by you | Define who may approve new users and role changes |
Two decisions fall out. First, the change pool is not optional: 18 enhancement asks in six weeks means a zero-hour pool would turn every request into a negotiation. Second, the 22 data fixes are a design signal, not a support volume to pay for forever, so the admin screen becomes the first change-pool item. None of this needs a price yet; it needs categories both sides agree on.
The bucket test: five questions for any new request
After go-live, new requests arrive daily. Use these questions in order and stop at the first yes:
- Does the system fail its accepted specification, inside the warranty window? Warranty. Send it to the build vendor with the test case reference.
- Is it a contract, account, approval or business rule that must stay in your name? Kept by you. The AMS provider may execute, but you decide.
- Does it keep today’s behaviour working without changing it? AMS run.
- Does it change what users see, what data is stored, or how an integration behaves? AMS change pool, with an estimate before work starts.
- Is it bigger than the pool can absorb in a quarter? Treat it as a small project with its own scope and approval.
Write this test into the AMS schedule so it becomes the tiebreaker when the two sides disagree on a ticket.
A 12-month maintenance calendar to attach
- Monthly: dependency and patch report; scheduled-job failure review; cloud cost note; change-pool burn and backlog review; data-fix ticket count.
- Quarterly: backup restore test; privileged access review signed by you; partner API deprecation watchlist; certificate and secrets expiry review.
- Yearly: runtime major-version upgrade window; disaster recovery rehearsal; breach-notification call-tree test; vulnerability assessment and penetration test; AMS scope review against the register.
A calendar turns “we monitor everything” into dates you can check: no quarterly restore record means no restore testing. Pair it with the measurable targets in observability SLOs before AMS handover.
Mistakes and traps
- Signing an SLA without a scope appendix. Fast response to an undefined scope still leaves the quiet jobs unowned.
- A zero-hour change pool. Every small request becomes a quote, and the business stops asking or starts using spreadsheets.
- Letting warranty and AMS overlap with no rule. Defects get billed to the AMS fee, or AMS tickets get pushed back to an unwilling build vendor. Use the bucket test.
- Accounts in the vendor’s name. Domain, cloud billing root, app-store and partner accounts belong to your company, full stop.
- Treating data fixes as free favours. Count them; frequent fixes are a case for a small admin tool.
- No owner on your side. An AMS provider needs one product owner who can approve change-pool work and sign access reviews.
FAQ
What should an AMS scope checklist include after go-live?
Every recurring job the system needs, sorted into warranty, AMS run, AMS change pool, or kept by you, with a named owner and evidence for each. Start from the 15-row register above.
Are runtime upgrades part of AMS run or a change request?
Patch and minor upgrades usually sit in run. Major-version upgrades often change behaviour and need testing, so most buyers plan them in the change pool with a target quarter ahead of the published end-of-support date.
Should our AMS provider sign anything about PDPA?
If the provider processes personal data for you, a written contract defining its role and its duty to report suspected breaches without undue delay is the practical minimum. Your counsel should confirm the wording; the accountability stays with your organisation.
How is this different from post-go-live support SLAs?
SLAs define severity and clocks; scope defines which jobs are covered at all. Read post-go-live support SLAs for the clocks, and use this register for coverage.
Next step
Before the build team rolls off, run one 60-minute session with your product owner, the build lead and the AMS lead. Walk the 15-row register, assign every row a bucket and an owner, and attach the result and the 12-month calendar to the AMS schedule. If you want a provider that starts from this register, see application management services in Singapore or contact WC1 to walk through your system’s list.