Cloud migration in Thailand: scope, costs and common mistakes

Cloud migration is a change to the way a system is hosted and operated. Moving virtual machines is only part of the work. Applications, data, access, connectivity and support arrangements all have to make the transition.

Choose an approach per workload

• Rehost: move the workload with limited application change.
• Replatform: improve selected platform components while retaining much of the application.
• Refactor: change the application architecture to meet a defined need.
• Replace: adopt a different application or service and migrate the required data and workflows.
• Retain: leave a workload where it is when a move is not justified.

These are planning options, not a maturity ladder. Different parts of the estate can need different approaches.

Count the whole cost

Include compute, storage, data transfer, licenses, connectivity, monitoring, security tools and backup retention. Add discovery, migration engineering, training and parallel operation during the transition. Separate one-time work from recurring costs.

For illustration, the Thai edition considers 15 servers, roughly 2 TB of data and a five-person IT team, with a broad first-year planning range of THB 1.1–2.2 million. This is a hypothetical budget exercise, not a current provider quote or a forecast for your system. Individual line items and assumptions must be recalculated; a server count alone cannot produce a reliable estimate.

Benefits are conditional

Cloud can make capacity and managed services easier to obtain. It does not automatically make an application cheaper, more secure or more available. An oversized workload or a poorly controlled data-transfer pattern can remain expensive after migration.

Five mistakes to avoid

Skipping discovery

Inventory the application, data stores, scheduled tasks, integrations, accounts and actual resource usage. Document unsupported components and unknown owners.

Underestimating dependencies

A server may depend on identity, DNS, a shared file system or a service that is not moving. Map these connections and test latency and failure behavior.

Leaving security and data requirements until the end

Agree access controls, encryption, logging, region selection and applicable contractual or regulatory requirements before choosing the design. A region label alone does not establish compliance.

Ignoring cost governance

Set ownership, tagging, budgets and a review cadence. Track storage growth and idle resources, and understand commitments before purchasing them.

Forgetting the people who operate the system

Update runbooks and incident contacts. Rehearse deployment, restoration and rollback. Explain the changed workflow to users and support staff.

A pre-migration checklist

1. State the business reason and the measurable criteria for a successful move.
2. Complete the inventory and dependency map.
3. Review identity, network, data location and security requirements.
4. Build a cost model with a period of parallel operation.
5. Test data transfer and application behavior in the target environment.
6. Agree cutover approval, rollback triggers and verification responsibilities.
7. Confirm the team, coverage and budget for ongoing operations.

Start with a cloud assessment when the estate or costs are unclear. For a structured migration framework, see AWS migration strategies; the choice should still follow your workload rather than a vendor preference.