Writing a TOR for legacy system maintenance: clauses and risks
What a Thai TOR to maintain or take over an existing system should specify: a system inventory, takeover, measurable SLAs, acceptance evidence and exit.
By UNIXDEV Team · 18 min read
Original published · English edition
A TOR for maintaining a legacy system is the terms of reference an agency uses to hire a contractor to maintain or take over an information system that is already in use. It states what the system consists of, what the contractor must do and how that is measured, what evidence the inspection committee receives each period, and what must be handed back when the contract ends.
This guide is for IT staff and TOR drafting committees in Thai government agencies, and for procurement teams anywhere that need to contract out care of an existing system. It focuses on turning technical concerns into TOR wording that can be inspected. Procurement methods, e-GP and the public hearing on a draft TOR are covered in our guide to Thai government IT procurement, and what counts as a legacy system is explained in what is a legacy system. Legal texts were checked on 2 November 2026 against copies of the Royal Gazette pages published by Thai government bodies, linked in the sources. For the Ministry of Finance regulation we read the 2017 text and the amendments the Comptroller General's Department publishes (No. 2 of 2021 and No. 3 of 2026); neither changes the clauses cited here. English names of Thai laws below are our own translations.
How does a maintenance TOR differ from a development TOR?
A development TOR describes something that does not exist yet and is accepted as each milestone is delivered. A maintenance TOR describes something that already exists, which the drafter may only partly understand; the work repeats every month or period, and its quality shows in what does not happen: no outage, no lost data. The hard parts are describing the system well enough for bidders to price it, and defining evidence that proves the work in a period was actually done.
On classification, section 4 of the Public Procurement and Supplies Administration Act B.E. 2560 (2017) defines "supplies" to include services, and "services" as service contracts, contracts for services on a lump-sum basis, contracts for work and carriage under the Civil and Commercial Code, excluding hiring the agency's own employees, carriage for official travel, consulting, construction design or supervision, and hire of labour under the Civil and Commercial Code. System maintenance is therefore generally a service, but the classification of a specific contract should be confirmed with the procurement unit. We found no specific definition of "information system maintenance" in the Act or the regulation we read, so the TOR has to carry the detail.
Section 8 requires procurement to be value for money, transparent, efficient and effective, and auditable, and value for money includes having "an appropriate and clear supplies management plan". In our view, a TOR that says what the system is, how it must be cared for and how it will be handed over at the end is part of that plan. Who drafts the TOR and the steps before announcement are covered in the procurement guide.
What should the scope say when the agency does not fully know the system?
Put the system inventory in an annex rather than in the body text. Bidders use it to estimate the work; without it each one guesses the scope and prices cannot be compared. The annex should cover:
| Area | What to state |
|---|---|
| Applications | Name, purpose, language and framework with versions, user groups and hours of use |
| Databases and data | Database type and version, approximate data size, and whether it holds personal data |
| Servers and operating systems | Number of machines, operating system versions, location (agency server room or cloud) and who looks after the hardware |
| Environments | Whether production, staging and test are separate |
| Integrations | External systems, APIs, exchanged files, scheduled jobs and certificates that must be renewed |
| Licences and service accounts | Licensed software, domains, cloud accounts, who owns each account and when it expires |
| What the agency holds | Whether it has the latest source code, which documents exist, and whether backups have ever been restored |
Where the answers are incomplete, label the annex "information known to the agency at the time of drafting" and make the first period a discovery and takeover phase: confirm the inventory against the live system, report differences from the TOR, and list risks in the order they should be fixed. How to inventory an undocumented system is covered in taking over an undocumented legacy system. Also state what happens if discovery finds more work than the TOR describes (see the section on change below).
On naming technology, section 9 prohibits specifying supplies so that they match a particular brand or seller, unless the item has only one brand or requires parts of a specific brand. In our view, saying which language and operating system the existing system runs on is a fact of the work that bidders need. A qualification such as "must have maintained this system before" is different: only the incumbent can meet it. Describe the outcomes you need and experience with the same kind of technology instead. Whether a given clause conflicts with section 9 is for the procurement unit to judge.
Can the new TOR make the outgoing contractor hand over?
No. A new TOR and contract bind only the new contractor. Whether the outgoing contractor must deliver source code, passwords and documents depends on the existing contract, which is why government system takeovers often stall. Before drafting, do three things:
- Check the existing contract now for what it says about delivering source code, administrator accounts and knowledge transfer, and request those items before it ends. The list is in our vendor handover checklist.
- Write a takeover phase into the new TOR: the new contractor receives what the agency holds, checks that it builds and deploys, rotates shared credentials and reports what is missing.
- State the agency's own duties, such as granting access to machines and internal systems within a set number of days after signing, and naming who coordinates with the outgoing contractor. Takeover slows down when it waits for access.
The new contract is the chance to stop this happening again, by writing the end-of-contract handover in now (see the exit section below).
Source code, administrator accounts and documents: how to avoid lock-in
Keep what is needed to change maintainers in the agency's hands throughout the contract, rather than waiting for a handover at the end. Clauses to include:
- A repository the agency controls, where the contractor works with full history, rather than a zip file at the end of each period.
- Rights in work changed or added during the contract: state who holds them and whether others may continue to modify it. List separately any components whose rights belong to the previous contractor or a vendor.
- Build and deploy scripts and configuration, including infrastructure as code where it exists, delivered like source code.
- An administrator account register: which accounts exist, who holds them and when each password was last changed. Actual passwords stay in the agency's own vault, not in reports. Administrator-level accounts belong to the agency; contractor staff use named personal accounts that can be disabled when someone leaves the project.
- Documentation and runbooks updated every period: steps to start, stop and restore the system that someone else can follow. How to write just enough is in our undocumented takeover guide.
- A list of third-party components and licences: libraries and software the system uses, with versions and licence terms.
How do you write SLAs in a TOR so they can be measured?
No SLA figure is right for every system. Targets should follow from the impact of an outage, the hours of service needed and the budget, because tighter targets mean more on-call staff and higher prices. SLA figures are targets the contractor commits to work towards, not a guarantee that the system will never fail. What makes an SLA inspectable is that every metric has five parts: a definition, when the clock starts and stops, the measurement source, the reporting period and the exclusions.
| Metric | Definition to write | Measurement source | Target |
|---|---|---|---|
| Response time | From the time the ticketing system records a report to the time the contractor acknowledges it and starts work, by severity | A ticketing system the agency can view | Critical: within [__ minutes/hours] during [service hours] |
| Restoration time | From the report to the time users can use the main function again, even if the root cause is not yet fixed | Ticketing system and monitoring | Critical: within [__ hours] |
| Availability | Share of time the main function responds, measured from outside the system, excluding maintenance windows announced [__ days] ahead | Monitoring the agency can view | At least [__] per month |
| Restore test | Restore a backup to a test machine and confirm the data is usable | Test record with evidence | At least [__] per period |
| Vulnerability remediation | From the vendor's patch release or discovery of the vulnerability to patching or applying a compensating control, by severity | Patch status report | High: within [__ days] |
Exclusions worth stating include incidents caused by external systems or providers the contractor does not manage, and time spent waiting for agency approval or access. Severity definitions, pausing the SLA clock and service credits are covered in our MA and SLA contract checklist. Agree penalties with the procurement unit under the regulation currently in force; this guide does not state rates.
Why separate maintenance from change in the TOR?
Section 97 says a signed written contract or agreement cannot be amended except in the four cases it lists in (1) to (4): an amendment under section 93 paragraph 5; where an amendment is necessary and does not disadvantage the agency; where it is for the benefit of the agency or the public; and other cases set by ministerial regulation. Approval is at the discretion of the authorised person. If an amendment changes the contract value or duration, that must be agreed at the same time. Clause 161 of the Ministry of Finance Regulation on Public Procurement and Supplies Administration B.E. 2560 (2017) gives the head of the agency the authority to sign and amend contracts.
Because mid-contract amendment is limited, the TOR should answer three questions up front:
- What is maintenance, for example fixing defects so the system works as before, applying patches, monitoring, backups and listed minor configuration changes.
- What is change, for example new screens or reports, new integrations and moving to a new major version of a language or operating system.
- How change is handled: who requests it, how the contractor sizes it and assesses impact, who approves it and which budget pays. One option is a value or hours allowance for change written into the contract from the start; ask the procurement unit whether that works for your agency.
"Improve the system as users require", with no boundary, is a common source of disputes between agencies and contractors. A detailed change-request process is in our MA and SLA checklist.
How should a TOR handle patching on unsupported platforms?
Do not write "the contractor shall install all the latest security patches" if the operating system or framework is out of support. The vendor no longer issues patches, so the clause cannot be met or inspected. Write four parts instead:
- Record the support status of each component in the inventory annex, and have the contractor confirm it during discovery.
- Where patches still exist, apply them within set times by severity, with a test plan and a rollback plan.
- Where they do not, apply compensating controls such as network isolation, restricted access and extra monitoring, and report their status each period.
- Make an upgrade or migration recommendation report a deliverable, budgeted separately from the upgrade itself.
Compensating controls, extended support and how to check each product's end-of-support date are covered in keeping an end-of-support legacy system running safely.
Backups, logs and personal data: what goes in the TOR?
Backups and restore tests
State what is backed up (databases, files and configuration), how often [__], for how long [__], and that copies are stored apart from the main machines. More important, require a restore test every period, with a record of the date, what was restored, how long it took and how the data was checked. A backup that has never been restored has not been shown to work. If the agency has a disaster recovery plan, state how often it is rehearsed and who takes part.
Log retention
Section 26 of the Computer-related Crime Act, as amended by the second Act of B.E. 2560 (2017), requires a "service provider" to keep computer traffic data for at least 90 days, and allows an official to order retention beyond 90 days but not beyond two years in special cases. The duty applies to service providers as the Act defines them; it does not mean every system must keep logs for 90 days. Annex A of the Ministry of Digital Economy and Society (MDES) notification on traffic-data retention criteria for service providers, B.E. 2564 (2021) does, however, list "computer network access providers for organisations, such as government agencies, companies or educational institutions" as an example, so an agency that gives its staff network or internet access through its own systems should check with its legal unit whether the duty applies. The TOR should require the contractor to maintain whatever log retention the agency is obliged to keep, not to shorten retention or disable logging to save space without approval, and to report log retention status each period.
Personal data
A contractor maintaining a system that holds citizens' or staff data is usually a data processor. Section 40 of the Personal Data Protection Act B.E. 2562 (2019) requires a processor to act only on the controller's instructions, to put appropriate security measures in place and notify the controller of a breach, and to keep records of processing activities, and requires the controller to have an agreement with the processor governing that work. The TOR should therefore require a data processing agreement (DPA) attached to the contract. What a DPA should cover is in the procurement guide.
What evidence should each acceptance period require?
Section 100 has the authorised person appoint an inspection committee responsible for contract administration and acceptance. Clause 175 of the 2017 regulation sets out the committee's duties; the ones that matter most when drafting a TOR are:
- Inspect the work for correctness and completeness "according to the evidence agreed", and for technical tests, the committee may invite experts or qualified persons to advise (clause 175(2)).
- If delivery is correct but incomplete, or complete but not entirely correct, accept only the correct part, unless the contract says otherwise, and promptly report to the head of the agency through the chief procurement officer so the contractor is notified within 3 working days, counted from the day after the problem is found (clause 175(5)).
- Decisions of the inspection committee must be unanimous; a dissenting member records the objection (clause 27).
When every member must agree, a criterion such as "the contractor keeps the system working normally" is hard to judge. The TOR should list concrete deliverables for each period, for example:
| Deliverable | Evidence | What the committee checks |
|---|---|---|
| Period report | Ticket export from the ticketing system | Ticket counts and response times match the system and are compared with SLA targets |
| Availability | Report from the monitoring system | Figures against target, and announced maintenance windows |
| Restore test | Test record with screenshots or logs | Done on schedule, and the restored data is usable |
| Patch status | Components, versions and patches applied | Patchable components patched on time; unsupported ones have compensating controls |
| Changes to the system | Commits or tags in the agency's repository | Match the tickets and approved change requests |
| Documents and accounts | Updated runbook and account register | Updated for the work done, with no accounts left for people who have left the project |
If a period needs a technical check, such as a restore test in front of the committee, describe the method in the TOR so both sides prepare for the same test. Amendments No. 2 and No. 3, which we checked, do not change clause 175; confirm the current text with the procurement unit or the Comptroller General's Department before relying on it.
What should the exit and transition clause contain?
Section 103 lets the authorised person terminate a contract on listed grounds, including "other grounds specified in this Act or in the contract or agreement" (section 103(3)). Termination grounds and the contractor's duties when the contract ends, whether on schedule or early, should therefore be written into the contract and TOR from the start. Include:
- [__ days] before the end, deliver a handover package: the latest source code, the account register, documents and runbooks, open tickets and known unresolved issues.
- Knowledge transfer to the next contractor or the agency's team for [__ days or hours], stating whether it is included in the price.
- No deleting data, closing accounts or changing passwords without notice during the transition.
- Return or deletion of personal data as the DPA requires, with evidence.
- All of this applies both at expiry and on early termination.
This clause also makes the agency's next TOR easier to write, because the inventory and documents will be current.
Common risks in legacy-maintenance TORs
| Risk | Sign in the TOR | Clause that reduces it |
|---|---|---|
| Vendor lock-in | No delivery of source code, accounts or documents | Agency repository, account register and documents delivered every period, plus an exit clause |
| Knowledge held by one person | No runbook or backup owner required | Updated, inspectable runbooks; named lead and backup staff; personal accounts |
| Unsupported operating system or framework | "Install all the latest patches" | Support status in the annex, compensating controls and an upgrade recommendation report |
| Blurred line between maintenance and new work | "Improve the system as users require" | Definitions of maintenance and change, and a change-request process |
| Acceptance by signature without evidence | "Submit a monthly report" with no required content | A list of per-period evidence exported from real systems |
| TOR fitted to the incumbent | "Must have maintained this system before" | Describe system facts and required outcomes, and let the procurement unit assess section 9 |
Checklist of TOR clause headings (copy and adapt)
These are our recommended headings, not an official form. Copy them as an outline and have the procurement unit review the result.
- Objectives, contract duration and payment periods
- System inventory annex: applications, databases, servers, versions, integrations, environments, licences and support status
- First period: discovery and takeover, confirmed inventory, gap report and risk list
- Agency duties: access, a named coordinator and coordination with the outgoing contractor
- Maintenance scope: what is included and what is not
- Change: definition, and how requests are made, sized, approved and funded
- Severity levels and SLA metrics: definitions, clock start and stop, measurement source, reporting period and exclusions
- Reporting channels and service hours
- Patching, unsupported components and compensating controls
- Backups, retention, restore tests every period and disaster recovery
- Log retention in line with the agency's obligations
- Security and the administrator account register
- Personal data and the data processing agreement (DPA)
- Source code, repository, build and deploy scripts, documents, runbooks and rights in modified work
- Deliverables and acceptance evidence for each period
- Contractor's lead and backup staff
- Handover at expiry or termination, and knowledge transfer to the next contractor
- Termination grounds written into the contract (drafted with the procurement unit)
Assess the existing system before drafting the TOR
A TOR written from the facts of the system makes bids comparable and gives the inspection committee something to judge each period against. If the agency does not yet know what the system contains, what is missing and where the risks are, an assessment before drafting produces the inventory annex directly.
UNIXDEV's legacy application maintenance service starts by assessing the source code, dependencies, deployment, data and rights holders, then delivers an overview of the system and its gaps, a risk list with a fix order, a takeover plan with backup, restore and rollback, and an MA scope that separates fixes, maintenance and new features.
We do not promise zero downtime; the interruption a change needs can be estimated only after reviewing the real architecture and dependencies.
UNIXDEV is registered as a vendor in e-GP and certified to ISO 9001:2015, ISO/IEC 29110-4-1:2018 and ISO/IEC 27001:2022. If an agency wants the same firm to assess the system and later bid on the same project, it should first ask its procurement unit whether any restriction applies.
Send what you know about the system, such as its name, technology, number of servers and what was received from the previous contractor, through the project brief form.
Sources and further reading
- Public Procurement and Supplies Administration Act B.E. 2560 (2017): Royal Gazette vol. 134, part 24 Kor, 24 February 2017 (sections 4, 8, 9, 97, 100, 103), in Thai · copy published by the Comptroller General's Department
- Ministry of Finance Regulation on Public Procurement and Supplies Administration B.E. 2560 (2017): Royal Gazette vol. 134, special part 210 Ngor, 23 August 2017 (clauses 27, 161, 175), in Thai · copy published by the Comptroller General's Department, read with amendments No. 2 (2021) and No. 3 (2026), which do not change the cited clauses; confirm the current text with the procurement unit or the Comptroller General's Department
- Personal Data Protection Act B.E. 2562 (2019): Royal Gazette vol. 136, part 69 Kor, 27 May 2019 (section 40), in Thai · copy published by the PDPC Office
- Computer-related Crime Act (No. 2) B.E. 2560 (2017): Royal Gazette vol. 134, part 10 Kor, 24 January 2017 (section 26 as amended by section 17), in Thai · copy
- MDES notification on traffic-data retention criteria for service providers B.E. 2564 (2021): Royal Gazette vol. 138, special part 188 Ngor, 13 August 2021 (Annex A), in Thai · copy
- Related: Thai government IT procurement, e-GP, the TOR and maintenance budgets
- Related: MA and SLA contract checklist
- Related: switching software vendors, what to take over
- Related: taking over an undocumented legacy system
- Related: keeping an end-of-support legacy system running safely
- Related: what is a legacy system
- Related: why government IT projects fail
- All articles on IT systems for government agencies
- All articles on maintaining and improving legacy systems
By the UNIXDEV Team · 2 November 2026 · A planning summary, not legal advice. Legal texts checked against government-published copies of the Royal Gazette as of the date of writing.