Kuala Lumpur & Bangkok · serving Thailand
Cloud Migration Services
Aqvantiq plans and executes cloud migrations for organizations in Thailand, from a single application to a full data-centre exit. We assess the estate, build the landing zone in Terraform first, move workloads in waves, and stay through cutover. Delivery is in English from Kuala Lumpur, with onsite time in Bangkok.
- Data-centre exits · workload moves
- AWS · Google Cloud · Huawei Cloud · Azure · DigitalOcean
- Landing zone in Terraform first
- Rehearsed cutover and rollback
Choosing a cloud for a Thai company
The one that fits the workload, the residency requirement and the skills you already have. Thailand is no longer a compromise market: AWS, Google Cloud and Huawei Cloud all run infrastructure in-country, so keeping production data in Thailand is a normal design choice rather than an exception you argue for.
-
AWS
Asia Pacific (Thailand), ap-southeast-7 — generally available 7 January 2025
The group already runs AWS, or the estate needs the widest managed-service catalogue.
Newer than Singapore. Confirm service-by-service availability before committing a wave.
-
Google Cloud
Bangkok, asia-southeast3 — launched 21 January 2026
Analytics and AI are the centre of gravity — warehousing, streaming, model serving.
The newest of the three. Validate quota early; plan interconnect before bulk transfer.
-
Huawei Cloud
Local infrastructure in Thailand, since 2018
Public-sector adjacency, or a hybrid design that keeps part of the estate on Huawei Cloud Stack.
Tooling and API surface differ. Terraform still drives it; budget time for the differences.
Azure and DigitalOcean stay in the picture as origins and as systems cheaper left alone. A plan that recommends moving everything is a sales document. Malaysian equivalent: cloud migration in Malaysia.
How an Aqvantiq migration runs
Six phases, in order, with a rehearsal before every irreversible step. The landing zone is built in code before a single workload moves, a pilot wave calibrates the estimates, and cutover runs against a written checklist with a named decision owner and a tested rollback.
- 1
Assessment and inventory
Dependency map, data volumes, licence constraints, an RTO and RPO per system. Each workload gets a pattern and a wave number.
- 2
Landing zone
Accounts, network, connectivity, identity, logging, backups and guardrails — in Terraform, so environments are rebuilt rather than remembered.
- 3
Pilot wave
One low-risk system end to end. Proves the runbook, the data-sync method, the restore and the real cutover duration.
- 4
Migration waves
Dependency-grouped batches. Continuous replication where the source supports it, rehearsed dump-and-restore where it does not.
- 5
Cutover and rollback
DNS TTLs lowered days ahead, a written verification checklist, a named decision owner, a rollback that has been tested.
- 6
Operate or hand over
Your team takes it with runbooks and a walkthrough, or we keep running it. We do not disappear at cutover.
Where the delivery pipeline is part of the problem, the migration runs alongside DevOps as a Service in Thailand, so the new environment arrives with a working deployment path.
Lift-and-shift, replatform or refactor
Per workload, not per estate. A deadline-driven data-centre exit is mostly rehost, with replatforming applied afterwards where it pays. Refactoring is justified when the application is what holds the business back. Mixing patterns deliberately is normal; applying one pattern to everything is how migrations overrun.
| Pattern | What changes | Best when | Watch out for |
|---|---|---|---|
| Rehost (lift-and-shift) | Servers move as they are. The application is untouched. | A hard deadline — lease ending, hardware end of life, a landlord exit. | You inherit every existing problem, and the bill stays near the old one until you optimize. |
| Replatform | Managed database, managed load balancing, containers. The application keeps its shape. | You want operational relief and cost improvement without opening the source code. | Engine versions and stored-procedure behaviour. Test on real data volumes, not a sample. |
| Refactor | The application is split or rebuilt around cloud-native services. | The application is the constraint on the business, not the infrastructure under it. | The longest path, and it needs product commitment. Not during an exit deadline. |
| Repurchase or retire | The system becomes a SaaS subscription, or is switched off. | Low-value or duplicated systems nobody wants to own for another five years. | Data extraction and retention obligations. Decide where the archive lives first. |
Data residency and the PDPA
Thailand's Personal Data Protection Act governs personal data, and many Thai boards want production data physically in-country regardless of what the law strictly requires. All three platforms provide in-country infrastructure — whether the full workload satisfies a residency requirement still depends on the services and data flows used, which is exactly what we design for: the line your legal team draws, with the whole data lifecycle kept on the same side of it.
The parts that get forgotten
Backups, log archives, monitoring data, disaster-recovery copies and non-production datasets. A database in Bangkok with backups landing abroad is a residency failure that passes every architecture review.
How we control it
Region-pinned storage and keys, explicit deny on unwanted cross-region replication, named least-privilege roles with audited access, and cross-border disaster recovery only where it is signed off in writing.
How long a migration takes
Three things decide it: data volume, dependency depth, and how many change windows the business will grant. A single web application with a modest database is a matter of weeks. A mixed estate with shared databases and licence constraints runs in waves over months. We give the number after the pilot wave, when it is measured.
Cloud migration in Thailand — frequently asked questions
Can't find your answer?
Ask it directly and an engineer answers, usually the same working day.
Ask an engineer How long does a cloud migration take?
Three things decide it: data volume, dependency depth, and how many change windows the business will grant. A single web application with a modest database is a matter of weeks. A mixed estate with shared databases and licence constraints runs in waves over months. We give the number after the pilot wave, when it is measured rather than estimated.
Can you migrate us out of a Thai data centre or co-location provider?
Yes — that is the most common starting point. Typical origins are on-premises VMware estates, co-located racks and single-tenant hosting. We connect the source to the target over VPN or a dedicated link for the transfer window, migrate in dependency-grouped waves, and keep the source running until verification passes.
Do you migrate to Huawei Cloud as well as AWS and Google Cloud?
Yes. Huawei Cloud is a first-class target for us, including hybrid designs where part of the estate stays on-premises on Huawei Cloud Stack because policy requires it. Details are on the Huawei Cloud services page. Very few integrators in this region will build on AWS, Google Cloud and Huawei Cloud equally.
How do you handle data residency and Thailand’s PDPA?
We design to the residency line your legal and compliance team draws, then keep backups, logs and disaster-recovery copies on the same side of it — those are the three that get forgotten. AWS, Google Cloud and Huawei Cloud all now run infrastructure inside Thailand, so in-country production data no longer forces an architectural compromise.
How much downtime should we expect at cutover?
It follows the data-sync method, not the vendor. Continuous replication usually means a switch measured in minutes; dump-and-restore means hours, bounded by database size and network throughput. We measure it during the pilot wave and rehearse the cutover before the real one, so the number you are given is observed rather than promised.
What actually slows a migration down?
Not the cloud. Undocumented dependencies, a change-approval process nobody mapped, and data that turns out to be larger or dirtier than the inventory claimed. The assessment phase exists to find those early, while they are still cheap to fix, rather than during a cutover window.
Do you compare Thai and Malaysian regions for groups operating in both countries?
Yes. For groups on both sides of the border we compare Thai and Malaysian regions before defaulting to one. AWS runs regions in both markets, so a two-country design sits inside a single provider. The same group of engineers and the same Terraform standard cover both — see cloud migration in Malaysia.
Will our team be able to run the environment afterwards?
That is the design goal. Infrastructure is delivered as Terraform in your repositories, with runbooks and a live walkthrough for your engineers. If you would rather not carry day-2 work, managed cloud services in Thailand continues from the same codebase rather than starting a new one.
Working to a data-centre exit date
Send the estate, the deadline and the constraint you cannot move. You get a reply from the engineer who would run it.