How to migrate to AWS in Thailand? An explanation of the challenges and migration procedures for local subsidiaries.

For companies operating on-premises environments or existing systems at their Thai base, migration to Amazon Web Services (AWS) becomes a viable option due to aging servers, maintenance burdens, and lack of scalability. Using the AWS Asia Pacific (Thailand) region allows for the establishment of an AWS environment within Thailand.

During the migration, we will organize the dependencies of the current system, inter-site network, costs, duration, downtime, PDPA, and data storage requirements, and design the monitoring and operation after the switchover to production.

This article explains the reasons for considering AWS migration in Thailand, things to check regarding the Thailand region, migration procedures, costs and timelines, the division of roles between the Japanese head office and the local subsidiary, and how to choose a support company.

Reasons and benefits of considering AWS migration in Thailand

For on-premises environments at Thai bases, server obsolescence, maintenance contract renewals, troubleshooting, and equipment expansion are ongoing burdens. Some companies are unable to secure sufficient IT personnel locally and rely on their Japanese headquarters or external vendors for support.

With the opening of the AWS Asia Pacific (Thailand) region, it has become easier to choose AWS as a migration destination for systems that prioritize data placement within Thailand and fast response times from local users.

Migrating to AWS reduces the procurement and maintenance of physical equipment and allows you to scale resources up or down according to usage. Backup, monitoring, and security can also be designed by combining AWS services, providing an opportunity to review your operational structure, business continuity, and infrastructure costs.

We are facing challenges in maintaining and expanding our on-premises environment.

In an on-premises environment, you manage the maintenance deadlines for servers, storage, and network equipment, and develop upgrade plans to prepare for failures and performance issues. Each time you add or replace equipment, you need to select, procure, install, configure, and verify its operation.

In Thailand, it can be difficult to immediately secure the necessary equipment and maintenance personnel. Coordination with local vendors and approval from the Japanese headquarters can take time, sometimes preventing timely upgrades. If configuration and troubleshooting depend on specific individuals, transfers or departures can also pose operational risks.

AWS allows you to add computing and storage without purchasing physical equipment. It also eliminates the need for system-wide upgrades to coincide with maintenance expiration dates, and allows you to adjust the configuration according to workload and user numbers.

This reduces the operational burden on local businesses and enhances business continuity.

Local IT staff sometimes handle all aspects of the business, including internal systems, network management, terminal administration, and user support. When server failures or capacity shortages occur, they are overwhelmed with troubleshooting and equipment replacement, which impacts their core business operations.

AWS allows you to remotely monitor operational status, logs, backups, and security events. You can also establish a system where your Japanese headquarters or operations support company monitors your systems and assists with troubleshooting and recovery.

By combining distributed deployment across multiple availability zones, backup, and recovery procedures, you can prepare for equipment failures and site-side problems. However, availability, backup destinations, recovery time, and communication routes must be designed separately.

Migrating to AWS allows you to review your infrastructure costs.

In on-premises environments, companies often purchase more servers and storage than they actually need, anticipating future increases in usage. This involves not only equipment costs, but also expenses for maintenance, installation space, power, air conditioning, and backup equipment.

AWS uses a pricing model based on the resources and data transfer volume you utilize. You can start with the capacity you need and increase or decrease it as your usage increases, eliminating the need to maintain excess capacity. Long-term pricing plans and the ability to stop or delete unused resources are also effective for cost management.

On the other hand, simply migrating the current configuration may result in excessive specifications or unnecessary resources remaining, leading to usage fees exceeding expectations. Before migration, we investigate current costs and usage, and compare configurations, pricing plans, and operating costs.

Points to check when migrating to the Thailand region

The AWS Asia Pacific (Thailand) region became generally available in January 2025. Its region code is "ap-southeast-7" and it consists of three Availability Zones.

When selecting a migration target, check latency, data placement, available AWS services, and availability.

Check latency from within Thailand.

Using the Thailand region reduces the physical distance from users and locations within Thailand to the AWS environment.

However, response speed is not determined solely by the region. Factors such as the network connection at the branch office, the carrier's routing, VPNs and dedicated lines, application processing, and connections to external services also play a role.

Before the migration, we will measure screen display, file transfer, database processing, etc., at actual usage locations. If there are factories or sales offices outside of Bangkok, we will also check the communication routes, line quality, bandwidth, and alternative routes in case of failure from each location to the Thailand region.

When using the service from our Japanese headquarters or from outside Thailand, we verify whether acceptable performance can be obtained from each connection source.

Organize the data placement and PDPA requirements.

Using the Thailand region allows you to store your data on AWS infrastructure located within Thailand. If domestic storage is required by your contract, internal regulations, or industry requirements, this can be a factor in deciding on a migration destination.

However, simply storing data within Thailand does not complete compliance with the PDPA. Considering the collection, use, disclosure, protection, and transfer of personal data, we must clarify the data types, purposes of use, access rights, retention periods, and the division of responsibilities with contractors.

Japanese companies may consider a configuration where business data is stored in Thailand, while the Japanese headquarters accesses the management screen and logs. We will examine not only the location where the data itself is stored, but also backups, log transfers, integration with external services, and data sharing during incident investigations.

When accessing data from our Japanese headquarters or outside of Thailand, we will consult with our legal and security departments to determine if the handling of the data constitutes a cross-border data transfer.

Check if it supports the AWS services you plan to use.

AWS service availability varies by region. If the service you need is not available in the Thailand region, you will need to consider configuration changes or alternative services.

Databases, monitoring, security, backup, analytics, and generative AI may have different features and availability dates. Check not only the service name, but also the engine, instance type, features, and version.

We will create a list of products and features in the current environment and match their availability with the migration destinations on AWS. If they are unavailable, we will consider replacing them with other services, deploying them to a different region, or excluding them from the migration.

Consider the configuration for availability and disaster recovery.

Distributing systems across multiple availability zones provides protection against failures in a single data center or facility.

However, simply distributing resources does not guarantee that the necessary availability and recovery requirements will be met. Depending on the criticality of the system, you should design server and database redundancy, backup, fault detection, and failover methods.

If you anticipate a complete region-wide outage, you should also consider backups to another region and disaster recovery environments. Compare recovery time targets, recovery point targets, data transfer costs, and maintenance costs to determine the necessary scope.

Steps to proceed with AWS migration in Thailand

The AWS migration will proceed in the following five steps:

1. Investigate the current environment and the targets for migration.
2. Determine the transition method and transition plan.
3. Design the AWS environment and network.
4. Perform a test migration and then switch to production.
5. Hand over to the operations manager after the migration.

The responsibilities of the Japanese headquarters, local subsidiaries, existing vendors, and migration support companies will also be clarified in the initial stages.

Investigate the current environment and the targets for migration.

First, we will understand the current environment's configuration and usage.

• Servers, databases, storage
• Network configuration and communication destinations
• System dependencies
• Data volume, communication volume, operating time
• Failure history and maintenance deadline
• OS, middleware, licenses
• Users and access routes
• Time periods when it can be stopped

The investigation also covers connections to systems that enable business operations, such as authentication infrastructure, external services, file transfers, nightly batch processing, printers, and factory equipment.

Based on the survey results, we categorize the systems into those to be migrated to AWS, those to remain on-premises, and those to be decommissioned, and then prioritize them based on difficulty and business impact.

Things to decide at this stage

• Subject to transition, retention, or abolition
• System dependencies
• Migration priorities

Determine the transition method and transition plan.

You will select a migration method for each system.

The migration method will be selected based on the challenges of the current environment, future expansion plans, available personnel, and acceptable downtime.

The migration plan will define the target systems, work sequence, responsible parties, testing period, and production switchover date. If there are dependencies between systems, a decision will also be made on whether to proceed in stages or switch over all at once.

We will also pre-determine the point at which we can revert to the old environment in case of failure, and the person responsible for deciding whether to continue or discontinue the project.

Things to decide at this stage

• System-specific migration methods
• Migration order and schedule
• Person in charge and approver
• Cutback conditions

Design the AWS environment and network.

Based on the migration plan, we will design the infrastructure on AWS.

• AWS account configuration
• VPC, subnets, routing
• IAM permissions
• Connections with our Thai office and our Japanese headquarters.
• Log source
• Monitoring items and notification recipients
• Backup frequency and retention period
• Encryption and security settings

In the networking phase, we will determine how to connect our Thai office, our Japanese headquarters, systems to remain on-premises, and external services. We will compare internet VPNs and dedicated lines, checking bandwidth, stability, and alternative routes in case of failure.

Monitoring and backups will be configured before the migration, ensuring they are ready for operation simultaneously with the production switchover.

Things to decide at this stage

AWS account and network configuration

• Permissions Management
• Monitoring and notification
• Backup and recovery methods

Perform a test migration and then switch to production.

Before switching to production, we will verify the migration procedure using a test environment and some data.

• Time required for data transfer
• System startup procedure
• How to change the connection destination
• Data integrity
• Operation of business functions
• Time required for pruning

We will verify not only server startup, but also login, data entry, searching, report output, file linking, batch processing, and other actual business procedures.

During the actual production run, we will proceed according to the procedure manual, stopping data updates, migrating final data, changing connection destinations, and verifying operation. We will set time slots when both the Thai office and the Japanese headquarters can respond, and we will also establish a communication channel to share work progress and decision-making results.

If a serious bug is found, we will revert to the old environment according to pre-defined conditions.

Things to decide at this stage

• Test items and passing criteria
• Switching to the main production environment procedure
• Determinant of start/completion
• Pruning criteria
• Contact system for the day

Hand over to the operations manager after the migration.

After the production switchover, the migration project will be handed over to normal operations.

• AWS environment configuration diagram
• Accounts and permissions
• Monitoring items and notification recipients
• Backup and recovery procedures
• Troubleshooting Procedures
• Change management methods
• Contact information and contact channels

Immediately after the migration, you may experience performance issues, communication errors, batch processing failures, and unexpected AWS usage charges. For a certain period, the migration team and operations team will jointly monitor the operational status and adjust settings as needed.

The Thai subsidiary, the Japanese head office, and external support companies will share responsibilities for initial response, root cause investigation, recovery decision-making, communication with users, and reporting to the head office. The operational launch criteria will be based on the functionality of monitoring and incident response.

Things to decide at this stage

• Operation manager
• Division of responsibilities for monitoring and incident response
• Escalation destination
• How to report to the Japanese head office
• Post-migration verification period

Costs and timeframe for migrating to AWS in Thailand

The cost and duration of an AWS migration are not determined solely by the number of servers. They depend on the system configuration, data volume, migration method, network, downtime, and testing scope.

The estimate covers everything from current environment survey, AWS environment design and construction, migration, testing, production switchover, and post-migration operation. Prioritizing only cost and time and cutting corners on survey and testing will increase the risks during the production switchover.

Check the factors that affect migration costs and the estimated costs.

The costs of migrating to AWS mainly consist of the following items:

• Survey and assessment of the current environment
• Designing and building an AWS environment
• Server, database, and data migration
• Building a network connection
• Testing and production switchover
• Post-migration monitoring and operation
• AWS monthly usage fees

If the existing configuration is not significantly altered and the number of target systems is small, the scope of investigation and design can be kept to a minimum. On the other hand, if integration of multiple systems, database changes, application modifications, or the construction of dedicated lines are required, costs will increase.

After the migration, in addition to the usage fees for Amazon EC2 and Amazon RDS, you will also incur costs for data transfer, backup, log storage, monitoring, and support.

When requesting an estimate, please provide the following information to the support company:

• The number of systems and devices to be migrated
• Data volume and communication volume
• Current environment configuration
• Transition method
• Possible stop time
• Test Coverage
• Scope of operation after migration

Instead of using a fixed market price, we compare quotes that clearly specify the breakdown of costs and the underlying assumptions.

Let's organize the factors that will influence the transition period.

The transition period is calculated by adding up the time required for current system analysis, design, construction, testing, and production rollout.

The main factors causing fluctuations are as follows:

• Number of systems to be migrated
• System dependencies
• Data volume and transfer speed
• Whether or not the application has been modified.
• Preparing the network connection
• Availability of a test environment
• Internal approval and vendor coordination
• Dates and times when it can be stopped

While rehosting can be carried out relatively quickly, a lack of information about the current environment or the need to coordinate with multiple vendors can make the investigation and planning process time-consuming. Replatforming and refactoring require design changes, modifications, and additional testing, resulting in longer timelines.

In the migration plan, instead of simply deciding on the production switchover date, we will set completion conditions and approvers for each stage. The schedule will also include confirmation periods for the Thai subsidiary, the Japanese head office, existing vendors, and support companies.

Estimate downtime and impact on operations.

During the production system switchover, data updates will be stopped, final data transfer will be performed, connection destinations will be changed, and operational checks will be conducted. The target system may be unavailable during this time.

The main factors that affect the downtime are as follows:

• Amount of data to migrate
• Baseline bandwidth
• Whether differential synchronization is possible
• Time required for system startup and verification
• How to switch DNS and connection destinations
• Pruning procedure

There are methods such as transferring most of the data in advance and synchronizing only the differences on the day of the event, or switching the system in stages. However, the available methods will vary depending on the system configuration.

The following items should be checked regarding the user department.

• Days and times when service can be stopped
• Services unavailable during downtime
• The extent to which manual work can be replaced
• Information for customers and business partners
• Time to decide when to prune back
• How to confirm the resumption of business operations

If the Thai office and the Japanese headquarters use the same system, the operating hours and time differences of both locations will be taken into consideration, and the impact on operations and recovery decisions will be reflected in the production switchover plan.

Division of roles between the Japanese head office and the Thai subsidiary

In the AWS migration, we will divide the responsibilities of the Japanese headquarters, the Thai subsidiary, and external support companies. The headquarters will manage policies, budgets, and security standards, while the local subsidiary will organize operational requirements and the impact on users. Even when outsourcing work to support companies, we will not entrust them with decision-making, but will clearly define the reviewers and approvers at each stage.

The actual division of responsibilities will vary depending on the local IT system and the management policies of headquarters. It will be decided who will review and make decisions at each stage: before the migration, on the day of the migration, and after the migration.

Scope managed by the Japanese head office

The Japanese headquarters is responsible for matters related to company-wide policies and management standards.

• Objectives and scope of AWS migration
• Budget and Schedule
• AWS Account Management Policy
• IAM permissions and authorization rules
• Security and log management standards
• Backup and disaster recovery requirements
• Selection and contract of outsourcing partners
• Reporting standards for incidents and security breaches

If AWS accounts and administrator privileges are entrusted solely to local subsidiaries or support companies, the head office may lose track of the configuration and change history. The head office should also manage account ownership, who is granted administrator privileges, and who can review billing information.

During the actual migration, we will also designate individuals responsible for deciding when to initiate, continue, and roll back the migration. If approval from business units or management is required, we will also determine the approval process in advance.

Scope of responsibility of the local subsidiary

The Thai subsidiary will understand the local operations and usage environment and share this information with headquarters and support companies.

• Current system usage
• Users, business hours, busy periods
• Dates and times when it can be stopped
• Local lines and network equipment
• Coordination with local vendors and telecommunications operators
• Business Test
• Notification to users regarding suspension and resumption
• Inquiry reception after migration

Even if headquarters manages the system configuration, they may not be aware of how things are actually used, such as linking spreadsheets, shared folders, printers, factory equipment, and services from local vendors. The local team will identify the connections necessary for their business operations.

During the test migration, we will replicate and verify normal business operations, including login, data entry, report generation, and integration with external services.

Scope of outsourcing to external support companies

External support companies can be commissioned to handle technical surveys, design, construction, migration, and operational support.

• Investigation of the current environment and system dependencies
• Development of transition methods and transition plans
• Designing AWS Accounts and Networks
• Security, monitoring, and backup design
• Building an AWS environment
• Server and data migration
• Test migration and production switchover
• Creation of configuration diagrams and operating procedure manuals
• Post-migration monitoring and incident response

The company will determine the migration objectives, downtime, operational requirements, and security standards. The support company will present technical options and risks, and the head office and local subsidiary will decide on the course of action.

Before signing the contract, we will agree on the scope of work, roles during the production switchover, deliverables, delivery conditions, scope of operation after migration, and division of responsibility in the event of a failure.

Key points for choosing an AWS migration support company in Thailand

When choosing a support company, check not only their ability to build an AWS environment, but also the scope of their support, including current system analysis, production migration, and post-migration operations.

The relocation of the Thai office requires aligning the security and management standards of the Japanese headquarters with the local operational requirements and network environment. This involves comparing not only technical capabilities and costs, but also local coordination, reporting to headquarters, deliverables, and responsibilities.

Can you handle everything from current surveys to post-transition operations?

If you only request the design and construction of an AWS environment, the dependencies of your current system and monitoring and troubleshooting after the migration may not be covered.

We will determine which stages of the process can be entrusted to us, from current site survey and migration method selection to network design, security, monitoring, backup, test migration, production switchover, and rollback.

If you are handing over post-migration operations to another company, you need to confirm that the delivered system will include configuration diagrams, settings, monitoring items, backups, and troubleshooting procedures in a state where they can be easily transferred. Even if you entrust the operation to the same company, you should contract separately for the scope of responsibility for the migration work and normal operations.

Can you entrust the coordination with the Thai subsidiary to me?

The migration of the Thai base will require coordination with local user departments, IT personnel, telecommunications carriers, and existing vendors. Planning solely from the Japanese side may not reflect local business hours, network conditions, or specific usage patterns.

We will verify whether they can handle everything from interviewing on-site personnel and checking equipment and networks to coordinating downtime and test schedules, and managing the progress during the production switchover.

Coordinating with local telecommunications carriers and existing vendors may involve tasks such as confirming contract details, line installation, equipment setup, and procedures for allowing workers to enter the premises. Even if the project can be managed in Japanese, it is necessary to separately confirm who will be responsible for local coordination in Thai or English.

We will also confirm whether on-site visits are possible, the languages ​​supported, reception hours, the responsible office, and whether subcontracting is involved. Simply stating "Thailand support" or "Japanese language support" does not necessarily mean that on-site work and coordination are included.

Can you handle reporting to the Japanese headquarters and governance requirements?

If the Japanese headquarters manages the AWS environment, it is necessary to have a system in place to continuously monitor the configuration, changes, failures, and costs.

We will confirm whether the scope of support includes progress reports in Japanese, submission of configuration diagrams and design documents, record-keeping of change history, bug reports, monthly reports, and audit support.

We will avoid a situation where only the support company holds AWS accounts and administrator privileges. We will manage account ownership, permission recipients, configuration information, and billing information ourselves, so that it can be handed over after the contract ends.

We will pre-determine who will approve the change work, the scope of work that support companies can perform in emergencies, and which tasks can be reported afterward. Selection criteria will include not only technical qualifications and migration experience, but also the ability to reflect the management standards of the Japanese headquarters in local operations.

Serverworks supports AWS migration and operation in Thailand.

Serverworks provides support for migration from on-premises environments to AWS, including current site surveys, design, construction, and production switchover. We design AWS environments with post-migration operation in mind, including networking, security, monitoring, and backup.

For AWS utilization in Thailand, we can provide support that combines local assistance with reporting to the Japanese headquarters. Even if you haven't yet clarified the migration targets, costs, timelines, and roles, we can start by reviewing your current environment.

Summary

When migrating to AWS in Thailand, the plan should include everything from the dependencies of the current environment, networking, data placement, downtime, and post-migration operations.

It is necessary to clearly define the roles of the Japanese head office, the Thai subsidiary, and the support company, and to establish clear criteria for deciding when to switch to production and when to roll back.

When choosing a support company, make sure they can handle not only the construction of the AWS environment, but also current site surveys, on-site coordination, reporting to headquarters, and post-migration operations.