Skip to content
All projects

Com2us Platform · Migration

Zero-downtime migration from GCP to Tencent Cloud

Moved 80 servers and 20 databases of Summoners War: Chronicles from GCP to Tencent Cloud in about one week with no downtime.

Role
Cloud Engineer · Main engineer
Period
Feb 2023 – Feb 2026
Cloud
GCP · Tencent
Scale
80 servers · 20 databases
Key tech
Terraform · GCP · Tencent Cloud · Online Migration
80
Servers migrated
20
Databases migrated
0
Downtime

At a glance

1. Firewall firstNetwork and firewall rulesmatch GCP2. Online MigrationServers move with themigration tool3. Private validationSame infrastructure, checkedwith the dev team4. Phased trafficcutoverTraffic moves in stages aftervalidationGCPTencent Cloud80 servers · 20 databasesPrivate runLIVEAbout 1 week · 0 downtime · gcp.tf to tencentcloud.tf
It finishes in about one week with zero downtime, and the whole move is recorded from GCP Terraform code to Tencent Terraform code.

Problem

A live game had to move between clouds without stopping, and the firewall policy could not drift during the move.

Approach

Network and firewall rules were built on Tencent to match GCP first. Servers moved with the Online Migration tool and the same infrastructure was built. It then ran privately while the dev team checked for issues, and traffic moved in stages. The whole effort moved GCP Terraform code to Tencent Terraform code.

Result

The migration finished in about one week with no downtime. Some systems stayed on GCP while most game servers and databases moved to Tencent, and the firewall policy was fully reviewed and rebuilt along the way.

Up close

Phased traffic cutoverLIVEGCPTencent0%100%Zero downtime · about 1 week
All traffic now lands on Tencent, with zero downtime.
LIVEGCPTencent CloudFirewall rules firstOnline Migration · 80 server blocksPrivate validationTraffic cut overAbout 1 week · 0 downtimegcp.tf → tencentcloud.tf
Below the islands, the code: gcp.tf → tencentcloud.tf

What this code does: Module code that creates a Tencent Cloud security group and its rules. The first block creates the security group with its name, description, project, and tags only when creation is enabled (local.create), and the second takes lists of inbound (ingress) and outbound (egress) rules as variables and applies them to that group at once. Because the rules come in as variables, firewall rules organized on GCP can be rewritten into this list format to stand up the same policy on Tencent.

resource "tencentcloud_security_group" "sg" {
  count       = local.create ? 1 : 0
  name        = var.name
  description = var.description
  project_id  = var.project_id
  tags        = merge(var.tags, var.security_group_tags)
}

resource "tencentcloud_security_group_lite_rule" "lite_rule" {
  count             = var.create_lite_rule ? 1 : 0
  security_group_id = local.this_sg_id
  ingress           = var.ingress_for_lite_rule
  egress            = var.egress_for_lite_rule
}

What I learned

The first step in moving between clouds was not moving servers but pairing the two clouds' resources by role. Mapping network, subnet, firewall, and server first made it simple to turn GCP Terraform code into Tencent Terraform code, and the firewall policy could be fully reviewed and rebuilt along the way. Avoiding downtime came from not switching everything at once: the same infrastructure was built first and run privately while issues were checked with the dev team, and traffic moved in stages. The infrastructure ended up as code, but I learned that the traffic cutover steps also need to live as code and a runbook for the next migration to repeat the same result.

Related field notes

Open to work · Cloud infrastructure and security

Choose a theme

Click a badge to switch to that theme on the same content. Dragging only swings it.

Back to the front page →