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
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
Tencent security group resources (related public repository pf-03)
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.