From a single-VM database to Multi-AZ: moving a real-time gaming platform from Google Cloud to AWS
How a Southeast Asian real-time gaming platform moved three client sites and 15 VMs from Google Cloud to AWS in eleven weeks — databases replatformed to Amazon RDS for SQL Server Multi-AZ, a pilot cutover under 15 minutes, and a run-rate about 30% below the previous baseline.
Summary. A Southeast Asian operator of a real-time online gaming platform ran three client sites on 15 virtual machines in Google Cloud, each site depending on one hand-managed SQL Server VM. Skybit Technologies moved all three sites to AWS under the AWS Migration Acceleration Program in eleven weeks, replatforming the databases to Amazon RDS for SQL Server Multi-AZ and rehosting the application tier with AWS Application Migration Service. The pilot site cut over with under 15 minutes of downtime and 99.98% availability in its first week; the platform has run in production on AWS since December 2024 at a monthly run-rate roughly 30% below the previous cloud baseline.
At a glance
- Industry: Real-time online gaming platform (B2C sites and B2B white-label deployments)
- Region: Headquartered in Malaysia; players across Southeast Asia
- Source: Google Cloud Platform – 15 VMs (12 application, 3 SQL Server database)
- Target: AWS Asia Pacific (Singapore); one AWS account per client site
- Programme: AWS Migration Acceleration Program (MAP): Assess → Mobilize → Migrate
- Timeline: Assess mid-2024; Mobilize and Migrate October – December 2024
- Key services: Amazon EC2, AWS Application Migration Service, Amazon RDS for SQL Server (Multi-AZ, io2), Amazon S3, Amazon CloudWatch, AWS Systems Manager, AWS Secrets Manager, AWS CloudTrail
The challenge
The platform is delivered as three client sites, each a complete copy of the same five-component stack: a web/API frontend, the game backend, an asynchronous job processor, a Redis session cache and a SQL Server transactional database. Peak activity follows promotional and live-game events, so the platform is sensitive to database latency and to the availability of the transaction path.
Before the engagement the customer's readiness assessment recorded four problems:
- Cost with no lever. A fixed monthly bill for 15 VMs, with SQL Server licensing the largest single item, and no path to reduce it.
- Availability resting on single database VMs. Each site's SQL Server ran on one VM with no managed standby and no rehearsed recovery. The customer's target was an RTO of two hours or better and an RPO under 15 minutes – neither existed.
- A fixed-capacity, manual operating model. A two-person DevOps team, manual deployments of two to three hours per release, manually managed IAM roles and per-instance configuration.
- No security baseline or central observability, and no way to attribute cost per site.
The approach
Assess. A Migration Readiness Assessment across the six AWS CAF perspectives, interview-based portfolio discovery (the customer's policy prohibited automated scanning), a 7Rs classification and a business case built on a three-month billing baseline and an AWS Pricing Calculator estimate. The customer chose the Singapore Region for proximity to the source environment and its player markets.
Mobilize. One AWS account per site under consolidated billing, so each site's cost is visible on its own. Terraform modules with a per-site variables file, so the identical five-component layout could be deployed three times without drift. CloudWatch dashboards and alarms, Systems Manager Session Manager instead of SSH, Secrets Manager and Parameter Store for credentials and configuration, and a written cutover plan with objective rollback triggers (error rate, latency, unresolved critical alerts) and a 22:00–02:00 cutover window.
Migrate. Rehost of the 12 application VMs with AWS Application Migration Service; replatform of the three SQL Server databases to Amazon RDS for SQL Server Standard, License Included, Multi-AZ on io2 storage. The customer kept its existing Cloudflare edge in front of the sites – a deliberate decision to change as little as possible for players during the move.
Migrating the pilot first
The first site went live in mid-November 2024 with the asynchronous job processor as the first cutover application. Downtime was under 15 minutes. Over the first seven days the site measured 99.98% availability against a 99.9% target, sub-300 ms average response, an error rate under half a percent and single-digit-millisecond database latency. The remaining two sites followed over the next three weeks using the same runbooks, and the customer signed off the programme in December 2024.
Results
- Database tier – before: one SQL Server VM per site, no standby → after: Amazon RDS for SQL Server Multi-AZ with automatic failover and 14-day automated backups
- Recovery objectives – before: undefined → after: RTO under 60 minutes, RPO under 15 minutes, documented and rehearsed
- Pilot cutover – under 15 minutes of downtime; 99.98% availability in week one
- Monthly infrastructure run-rate – about 30% lower than the previous cloud baseline over the first eleven months in production*
- Deployment – before: manual, 2–3 hours per release → after: Terraform through a reviewed pipeline
- Cost visibility – before: one bill for three sites → after: one account and billing view per site
* Measured from AWS Cost Explorer for the three production accounts, December 2024 to October 2025, against the customer's pre-migration monthly baseline.
Lessons the team carried forward
- Validate cache and database dependencies before every DNS switch – service dependencies turned out to be more extensive than the inventory suggested.
- Extend performance tests to asynchronous job processing, not just the API.
- Enable GuardDuty and Security Hub at account provisioning, not after the first cutover.
- Verify a database restore immediately after every migration.
Why it matters
The migration did not re-architect the application. It moved the risk where it was – the database tier – onto a managed Multi-AZ service, gave a small team infrastructure as code and observability it did not have, and produced a per-site cost view that the business had never had. That is what a migration-first engagement is for: a stable, measurable foundation that modernization can build on later.
Skybit Technologies (GoShare Asia) is an AWS Advanced Tier Services Partner based in Malaysia, delivering migration and managed services for gaming and digital-native businesses across Southeast Asia. Customer identity withheld at the customer's request.

..png)
