Thai government cloud migration TOR: scope and acceptance

A TOR for moving a Thai government system to the cloud has to answer which systems move, where they go, which classes of data must stay in Thailand, how the move can be reversed, and what evidence the inspection committee uses to accept each period. The parts most often missing are who pays for the cloud once the migration is done, and how the agency leaves the provider when the contract ends.

This guide is for IT staff, TOR drafting committees and procurement officers in Thai government agencies preparing to contract a cloud migration. It focuses on turning technical concerns into clauses and acceptance evidence. Migration approaches, costs and cloud regions in Thailand are covered in our guide to cloud migration in Thailand; procurement methods and general software TOR headings are in our guide to Thai government IT procurement; and a TOR for maintaining an existing system is in writing a TOR for legacy system maintenance. Official documents were checked on 7 November 2026. Several Thai government cloud rules are still drafts and have already changed more than once. Thai dates below use the Buddhist Era (B.E. 2569 is 2026).

How does a cloud-migration TOR differ from a development or maintenance TOR?

A development TOR describes something that does not exist yet, and a maintenance TOR describes work that repeats every period. A migration TOR describes moving a system that already has users and live data. The risk concentrates in a short window around the move, and the consequences continue after handover, because cloud charges recur every month and the agency has to run the system on the target afterwards.

That is why a migration TOR needs four things other TORs often lack:

• Target and data class: which system goes to which kind of service, and which classes of data must be stored in Thailand.
• A reversible plan: a pilot, a cutover window, go/no-go and rollback criteria, and a parallel run where needed.
• Evidence that data arrived complete and correct, not just a screen that opens.
• Running cost and exit: who pays for the cloud, how it crosses budget years, and how to move out.

Which Thai government cloud rules should an agency know before drafting?

Some rules are already in force and others are still drafts. This table summarises their status on 7 November 2026 from the documents we could check; it is not a complete list.

The policy goes back to the National Digital Economy and Society Committee, which at meeting 1/2566 (22 December 2023) approved guidelines to drive a Cloud First Policy over five years, as recorded in the annex to the cloud security standard. We found no Cabinet resolution on Cloud First that we could verify from an official source, so we do not cite a date for one.

According to a focus-group deck from the Digital Government Development Agency (DGA) (24 December 2025, in Thai), resolution 3/2568 also made the Ministry of Digital Economy and Society (MDES) the Government Cloud Management body, and defines National Cloud as bringing the Government Data Center and Cloud service (GDCC) and agencies' own clouds under one set of standards, all connected to MDES's Cloud Management Platform (CMP). The same deck shows the approach changed during 2025: meeting 1/2568 (21 July 2025) put both "secret" and "top secret" data on a sovereign cloud, but the classification table approved on 28 November 2025 kept only "top secret" there. This article cites the latest version we could check, and the rules may change again. Before drafting, confirm them with DGA, the Office of the National Digital Economy and Society Commission (ONDE) and the agency's budget officer.

Where should the scope start?

With the system inventory and a dependency map. Without them, each bidder guesses the scope and the prices cannot be compared. The inventory annex headings, such as applications, databases, servers, integrations and licences, are the same as in the legacy-maintenance TOR. A migration needs these additions:

Make the first period discovery and design: an inventory confirmed against the real systems, a dependency map checked against actual traffic such as network connections and logs, a migration plan split into waves, and a report of where reality differs from the TOR. Choosing which systems to rehost and which to re-architect is covered in moving legacy systems to cloud-native. If discovery finds more work than the TOR states, say in advance how that will be handled, because section 97 of the Procurement Act limits changes to a signed contract, as explained in the legacy-maintenance TOR article.

DGA's draft cloud usage standard (December 2025) splits migration into four steps: assess risk and long-term cost against keeping the old system; choose a migration model; migrate and test step by step; and manage after migration, including keeping cost within budget and continuous tuning. These steps line up with the example five-period split in the acceptance section below.

How do you specify the target without naming a brand?

Section 9 of the Public Procurement and Supplies Administration Act B.E. 2560 (2017) (in Thai) prohibits specifications set close to any one brand or seller, unless the item has only one brand or needs a particular brand's parts. Describe the target as required characteristics instead: where data is stored at rest, the service type (IaaS, PaaS or SaaS), the certification evidence required, the connections required and the conditions for taking data out, rather than a provider or product name. Whether a given clause conflicts with section 9 is for the procurement unit to judge.

Thai agencies usually choose from three kinds of target:

• The government central cloud (Government Data Center and Cloud service, GDCC). According to NT's announcement (14 March 2023, in Thai), ONDE assigned National Telecom (NT) to run it, and agencies apply through the GDCC Smart Request Service. We could not verify the operator or service terms for 2026, so confirm them with ONDE. If the target is GDCC, the TOR should separate what the agency requests from GDCC itself from the contractor's work, when the resources will be ready and who coordinates.
• A cloud the agency procures itself, including providers with regions in Thailand (see the Thai cloud region table), where that year's procurement guideline allows it and with the CMP connection the fiscal 2027 guideline requires (see the cost section below).
• The agency's own data centre or a hybrid, for systems that should not move yet or data that must stay under the agency's control.

Whichever is chosen, require the cloud account or tenant to be opened in the agency's name, with the top-level account and the billing account held by the agency as far as the target service allows. The contractor works through individual accounts with multi-factor authentication that can be closed when a person leaves the project. If the account sits in the contractor's name, any future change of contractor starts with asking for the account back.

How does data classification decide the target and where data lives?

According to the same DGA deck, the cloud data-classification guideline approved on 28 November 2025 has five levels. The standards that would give it force are still being revised and put to public hearing.

Two notes to the table belong in the TOR. First, "data that should be in Thailand" means data at rest, not data in transit or being processed, so the TOR should state where data is stored at rest, including backups, snapshots and logs, not just where the servers are. Second, if data is later reclassified or declassified, the agency may change its cloud model to match, which is one more reason to have an exit clause.

The National Cloud guideline says government data is to be stored in Thailand as the main rule. Where a service storing data abroad is needed, for example because no comparable service exists in Thailand or for disaster recovery, it is at the discretion of the head of the agency, who must ensure that ownership, control and management of the data remain under Thai law. In the first phase, national-security systems and critical information infrastructure (CII) services are exempted from the normal criteria. If a system holds personal data, transfers abroad must also meet sections 28 and 29 of the PDPA, summarised in our cloud migration guide. A system that draws citizens' data from several agencies, such as a welfare information system, should be classified before a target is chosen.

What should the security requirements say?

The cloud security standard now in force

The National Cyber Security Committee announcement on cybersecurity standards for cloud systems B.E. 2567 (2024) (in Thai) was published in the Royal Gazette, vol. 141, special part 248 Ngor, on 10 September 2024, and the NCSA announcement of an integration plan to implement it for 2026–2030 (7 August 2026, in Thai) states that it took effect on 10 September 2026, which matches clause 2 of the Gazette text: it applies once two years have passed from publication. Its main points for a TOR, from a circulated copy with its annex (in Thai; a pre-publication copy whose clause 2 still says one year, so rely on the Gazette text):

• "Agency" means state agencies, regulators and critical information infrastructure organisations under the Cybersecurity Act 2019, so it is not limited to CII.
• Agencies using a public cloud must follow the standard according to the impact level of their data or information systems under the committee's 2023 standard on cybersecurity attributes, and do no less than the minimum requirements annexed.
• Personal data must be rated at least medium for confidentiality impact.
• Agencies send a summary report to the NCSA within thirty days of completing the work.
• The minimum requirements are split between cloud service customers and cloud service providers.

These duties belong to the agency and a contractor cannot discharge them for it. The TOR can, however, require the contractor to configure the minimum requirements that fall within its scope and to hand over the configuration and evidence the agency needs for its report to the NCSA. How to interpret each requirement should be confirmed with the agency's security officer or the NCSA.

A responsibility matrix

The major providers describe the shared responsibility model along the same lines. AWS says the customer's responsibility depends on the services it selects; Google Cloud says that in IaaS the bulk of security responsibility is the customer's; and Huawei Cloud says tenants manage service configuration, virtual networks, guest operating systems, data, accounts and key management. DGA's draft standard cites the UK NCSC model, in which the customer's share shrinks from IaaS to SaaS.

A migration involves three parties, the agency, the contractor and the cloud provider, so the TOR should include a matrix naming who is responsible for each part during the project and after handover.

Certification evidence from the cloud provider

According to DGA's deck, the provider-registration guideline the Digital Government Development Committee approved on 28 November 2025 sets three tiers. Tier 1 uses CSA STAR, ISO/IEC 27001, ISO/IEC 20000 and ISO/IEC 27701 and may serve Official data; tier 2 adds ISO/IEC 27017 and ISO/IEC 27018 and may serve Official and Protected data; tier 3 adds specific measures such as an isolated network and serves Highly Protected data only. Certification is valid for three years. The same resolution told DGA to revise the related draft standards and bring them back for approval before they are enforced, so the standards that would enforce the tiers are still drafts. If a TOR asks for this evidence, word it to match what each standard is:

• ISO/IEC 27001:2022 is the certifiable requirements standard for an information security management system. Ask for the certificate and a scope that covers the services and locations to be used.
• ISO/IEC 27017 (now ISO/IEC 27017:2026, edition 2, published 27 July 2026) and ISO/IEC 27018:2025 are control guidelines for cloud services and for protecting personal data in public clouds. Ask for evidence that the provider's audit covered these controls and state which editions are accepted, since certificates already issued may cite older ones.
• CSA STAR level 1 is a self-assessment and level 2 a third-party audit. State the level required; entries can be checked in the STAR Registry.

Personal data the contractor can access during the migration should be covered by a data processing agreement (DPA), with the headings listed in our government IT procurement guide.

What should the migration plan in the TOR include?

The mechanics of cutover and rollback, such as rehearsals, lowering DNS TTL and syncing data in advance, are covered in the cutover and rollback section of our cloud migration guide. The TOR's job is to turn them into requirements with the agency's own figures and with evidence.

• Pilot: name the system to move first, or have the contractor propose one in discovery, with pass criteria written before it starts. The pilot results adjust the plan for the next waves.
• Cutover window: the period during which the agency accepts each system being unavailable [__ hours, during __], and a definition of what counts as unavailable, such as users being unable to complete core transactions.
• Go/no-go: the checks before switching, who decides, and the last point at which the move can still be reversed.
• Rollback criteria: the conditions that trigger a rollback, such as reconciliation mismatches, failed tests of key transactions or exceeding the announced window, and how data created on the target gets back to the old system. Rehearse a rollback at least once before the real move.
• Parallel run: for systems whose outputs must be compared, state how long [__], which system holds the master data meanwhile, how outputs are compared and who pays for running both.
• Data reconciliation: record counts and checksums per table, totals of numeric data, and business spot checks by the data owners, delivered as a signed report.
• Hypercare and decommissioning: how long close support lasts [__], and the conditions before the old system is switched off, such as the rollback period having passed and a restore from backup on the target having succeeded.

RTO and RPO in the TOR

Use definitions that can be checked. In NIST SP 800-34 Rev. 1, the recovery point objective is "the point in time to which data must be recovered after an outage", and the recovery time objective is how long system components can be in recovery before the organisation's mission is affected. The agency sets the figures from impact and budget, for example "RTO no more than [__ hours] and RPO no more than [__ minutes] for system __". The brackets are blanks to fill, not values we recommend, and a restore test on the target is the evidence that they are met.

Avoid "zero downtime" without a definition and a way to measure it: the committee cannot inspect it, and bidders will price in a risk of unknown size.

What should the inspection committee check each period?

Clause 175 (2) of the Ministry of Finance procurement regulation B.E. 2560 (2017) (in Thai) has the inspection committee check delivery as complete and correct "according to the evidence agreed", and allows it to invite experts for technical tests; clause 27 requires the committee's resolutions to be unanimous (details in the legacy-maintenance TOR article). A migration therefore needs evidence each period that every member can judge the same way. An example split:

If a period needs a technical check in front of the committee, such as rebuilding an environment from infrastructure as code or restoring a backup, write the method into the TOR so the committee and contractor prepare the same way. Confirm the current version of the regulation with the procurement unit before use.

How should the exit clause prevent lock-in?

DGA's draft cloud usage standard says cloud exit should be planned from the start of migration planning, to prevent vendor lock-in. The contract should cover returning data, retention, post-termination support, related costs and data portability. Data should be kept in formats that can move between systems, the transfer tested and its integrity checked, and data securely deleted from the old system in line with personal data protection law, with the destruction checked and reported. The draft cannot be cited as a standard, but the exit clauses below belong in a TOR regardless:

• Returning data: formats usable without a provider-specific service, the time allowed [__ days], and who pays for data egress.
• Rebuildable configuration: infrastructure as code or configuration documents complete enough for another contractor to rebuild the environment, kept in the agency's repository from the target-preparation period.
• Administrator accounts and encryption keys under the agency's control, with an account register updated every period.
• Provider-specific services: the contractor identifies in the plan where it uses services that are hard to move away from, and the alternatives if a move is needed.
• Deletion with evidence: delete data from the old system once rollback is no longer possible, and from the old provider on exit, with evidence.
• Expiry or early termination: every exit term above must apply in both cases. General handover of system care is covered in the legacy-maintenance TOR article and the takeover list in switching software vendors.

For reference terminology on moving data and applications between providers, ISO/IEC 19941:2017 defines cloud interoperability and portability concepts.

Who pays for the cloud after migration, and what happens across budget years?

Cloud charges recur every fiscal year; they do not end when the migration is accepted. Thai government budget rules mean this has to be planned before the TOR is drafted.

• Budget under the integrated plan: according to DGA's deck, the fiscal 2027 cloud procurement guideline requires agencies to request cloud budget under the digital government integrated plan; requests outside it will not be considered. GDCC is the first choice. If GDCC is insufficient or lacks the service needed, or for continuing procurement, the integration committee may approve an exemption so the agency procures itself. Agencies that procure their own cloud must have the provider connect to MDES's CMP. The guideline applies only to agencies receiving the national budget.
• No transfers between budget units: the summary of the Cabinet meeting of 11 November 2025 (in Thai; item on exempting agencies from the 26 August 2025 resolution that paused cloud procurement) explains that budget set for one budget unit cannot be transferred to or used by another under section 35 of the Budget Procedures Act 2018, except as the regulation on transferring integrated budget allows. The summary itself asks readers to verify the official resolution with the Secretariat of the Cabinet.
• Gaps when services cross budget years: the background section of the same summary cites National Digital Economy and Society Committee meeting 3/2567 (22 October 2024): cloud projects that had to continue from 1 October 2025 were to ask the public procurement problem-ruling committee to allow contracts to take effect retroactively. It shows that without planning for the fiscal year boundary, a migrated system may have no contract covering its charges at the start of the next year.

So the TOR should state:

• Who pays for cloud resources during migration, during any parallel run and after acceptance, and whether service charges sit in this contract or a separate one.
• The billing model. DGA's draft standard says that where a service offers pay-per-use billing, it must be considered first, and calls for a pricing calculator used with a standard way of setting a not-to-exceed budget ceiling.
• Monthly cost reports by system, resource tagging, and alerts as spending nears a ceiling the agency sets [__].
• What happens at the end of a fiscal year or if the service contract lapses, for example the provider must not delete data within [__ days], and how renewal works.

Migration cost categories are in our cloud migration guide, budgeting for next year's maintenance is in our government IT procurement guide, and keeping project scope from overrunning is in preventing software project budget overruns.

Is there a circular specifically on procuring cloud services?

As of the date we checked, we found no Comptroller General's Department circular specifically on buying or leasing cloud services. Procurement follows the 2017 Procurement Act and regulation together with the cloud resolutions and guidelines above. Procurement methods, e-GP steps and the public hearing on a draft TOR are in our government IT procurement guide. One decision to make before drafting is whether cloud charges go in the same contract as the migration work or in a separate item; each choice affects acceptance and renewal across budget years, so discuss it with the procurement unit and the budget officer.

What mistakes are common in cloud-migration TORs?

Several of these are the same causes that stall government IT projects in general, summarised in why government IT projects fail.

Checklist: headings a cloud-migration TOR should include

These are the headings we recommend, not an official form. Use them as an outline and have the procurement unit and legal officers review the draft before use.

1. Objective, duration and periods for discovery, target preparation, pilot, main migration and handover
2. Inventory annex: systems, dependencies, data classes, windows when systems can stop, and systems not moving
3. Discovery deliverables: confirmed inventory, dependency map, migration plan by wave and a report of differences from the TOR
4. The target described as characteristics, without brand names, and how it fits that year's cloud procurement guideline (GDCC, or an approved exemption to procure separately)
5. Data location at rest, including backups, snapshots and logs, by data class
6. Tenant, top-level administrator and billing accounts in the agency's name
7. Requirements under the cloud cybersecurity standard B.E. 2567 and the evidence the contractor supplies for the agency's report
8. A responsibility matrix for the agency, contractor and cloud provider, during the project and after handover
9. Provider certification evidence, with the scope and editions accepted
10. A data processing agreement (DPA) for personal data
11. Pilot system and pass criteria
12. Cutover window, go/no-go and rollback criteria, rehearsals and parallel run
13. Data reconciliation method and who signs it off
14. RTO and RPO set by the agency, and restore tests on the target
15. Connection to the central cloud management platform (CMP) where the rules require it
16. Configuration or infrastructure as code in the agency's repository
17. Runbook, knowledge transfer and administrator account register
18. Who pays for the cloud in each phase, billing model, cost reports and what happens across budget years
19. Acceptance evidence for each period and the method for technical checks
20. Exit: data return, formats, time allowed, costs and deletion with evidence
21. Conditions for switching off the old system and deleting its data
22. Termination grounds and handover on early termination (drafted with the procurement unit)

Assess the systems before they move

A good TOR starts from the facts of the systems. If the agency does not yet know which systems depend on which, what class the data is and which systems can move as they are, an assessment before drafting produces the inventory annex directly.

UNIXDEV's cloud services cover comparing options; setting up networking, identity and permissions, a security baseline and monitoring on the target; migration with dependency mapping, rehearsed data migration and an agreed cutover and rollback; and ongoing operations. Our cloud work is mainly on Huawei Cloud, BytePlus Cloud and Oracle Cloud, with AWS and GCP supported where the workload fits. 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.

Setting the scope of work, the reference price and the selection criteria is the agency's job. As a vendor we can give technical input, for example by commenting during the public hearing on a draft TOR the agency publishes. If an agency wants the same firm to assess its systems and later bid on the same project, it should first ask its procurement unit whether any restriction applies. We do not promise zero downtime; the interruption a move needs can be estimated only after reviewing the real systems.

Send what you have, such as a list of systems, technologies, number of servers and the targets under consideration, through the project brief form.

Sources and further reading

• National Cyber Security Committee announcement on cybersecurity standards for cloud systems B.E. 2567 (2024): Royal Gazette vol. 141, special part 248 Ngor, 10 September 2024, in Thai · copy with annex (a pre-publication copy; its clause 2 still says one year, so rely on the Gazette text)
• NCSA announcement on the integration plan to implement the cloud cybersecurity standard, 2026–2030 (7 August 2026, copy published by the Land Development Department, in Thai)
• DGA: focus-group deck on government cloud management standards (24 December 2025, in Thai): Digital Government Development Committee resolution 3/2568, National Cloud, data classification, provider registration and the fiscal 2027 procurement guideline
• DGA: draft digital government standard on cloud usage (December 2025, circulated for comment; its cover says it must not be used or relied on as a standard; in Thai) · draft committee announcement proposing it apply from 1 October 2027
• Summary of the Cabinet meeting of 11 November 2025 (Government House, thaigov.go.th, item 6 on cloud; the document asks readers to verify the official resolution with the Secretariat of the Cabinet; in Thai)
• NT: the government central cloud (GDCC) (14 March 2023, in Thai)
• Public Procurement and Supplies Administration Act B.E. 2560 (2017): Royal Gazette vol. 134, part 24 Kor, 24 February 2017 (sections 9, 97), in Thai
• 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, 175), in Thai
• Shared responsibility: AWS · Google Cloud · Huawei Cloud · UK NCSC
• Standards: ISO/IEC 27001:2022 · ISO/IEC 27017:2026 · ISO/IEC 27018:2025 · ISO/IEC 19941:2017 · CSA STAR · NIST SP 800-34 Rev. 1 (RTO, RPO)
• Related: cloud migration in Thailand
• Related: moving legacy systems to cloud-native
• Related: Thai government IT procurement, e-GP, the TOR and maintenance budgets
• Related: writing a TOR for legacy system maintenance
• Related: MA and SLA contract checklist
• All articles on IT systems for government agencies
• All articles on cloud and system migration

By the UNIXDEV Team · 7 November 2026 · A planning summary, not legal advice. The agency's procurement and legal officers confirm the final TOR, and DGA, ONDE and the NCSA confirm the current cloud rules.