How do you achieve zero downtime on an e-commerce platform at scale?

Not by being careful. By designing for failure, validating the rollback before you need it, and executing cutovers with enough observability to know within minutes if something is wrong — plus the discipline to abort and roll back when signals are unclear rather than pushing through.

What made the Tokopedia migration playbooks reusable across business units?

They were written as standard artefacts rather than engagement notes: assessment, migration plan, cutover runbook and rollback procedure, each parameterised for a business unit rather than a specific service. Other units adopted them directly, which is what the Migration Hero recognition was really for.

What was the AliCloud to GCP migration stack?

Terraform for infrastructure, Ansible for configuration management, HashiCorp Packer for consistent base VM images, Consul for internal service discovery, Jenkins with Ansible playbooks for deployment automation, and Datadog with Grafana for monitoring. Service discovery deliberately did not assume a cloud, which is what made the workloads movable at all.

Tokopedia: AliCloud to GCP — Migration Hero

Overview

Tokopedia is one of Southeast Asia’s largest e-commerce platforms, serving tens of millions of users across Indonesia. Their infrastructure ran on Alibaba Cloud. The migration to GCP required zero service interruption — any downtime would affect transactions at scale.

Context

Tokopedia was consolidating infrastructure to GCP. Multiple business units had their own workloads on AliCloud, each requiring assessment, migration planning, and execution. I was brought in as part of the CloudCover team to lead migration execution.

Constraints

No service interruption. At e-commerce scale a cutover window is measured in transactions lost, not minutes elapsed. Every migration had to be reversible up to the moment traffic moved.
Multiple independent business units. Each owned its own AliCloud workloads, its own release cadence, and its own definition of “ready”. There was no single estate to migrate — there were many, in sequence.
A source cloud with no direct equivalents. Alibaba Cloud’s services do not map one-to-one onto GCP. Each had to be assessed rather than translated.
Reusability was part of the brief. Whatever we did for the first business unit had to be repeatable by teams we would not be sitting with.

Service Mapping

The assessment for each business unit started from the same mapping, then diverged where the workload demanded it:

Concern	On Alibaba Cloud	On GCP	Why not a like-for-like swap
Compute	ECS instances	Compute Engine, from Packer-built images	Base images were rebuilt rather than converted, so every instance was reproducible from source
Configuration	Per-host, largely manual	Ansible playbooks	Manual drift on the source side was the main reason cutovers were hard to predict
Service discovery	Cloud-native resolution	Consul	Deliberately cloud-agnostic, so a service moving did not force its callers to change
Provisioning	Console and scripts	Terraform	The primitives needed a written form before anything could be reviewed or rolled back
Monitoring	Mixed	Datadog + Grafana	Cutovers had to be observable in minutes, not reconstructed afterwards

What Was Done

Migrated VM-based workloads from AliCloud to GCP compute with zero service interruption
Standardized and documented migration plans for reuse across multiple business units
Built infrastructure using Terraform; managed configuration via Ansible
Created base VM images using HashiCorp Packer for consistent deployments
Implemented service discovery using Consul for internal service resolution
Set up monitoring and dashboards through Datadog and Grafana
Automated deployment flows using Jenkins and Ansible playbooks

Challenges

Every business unit was a fresh negotiation. The technical pattern stabilised quickly; the readiness of each unit did not. Sequencing was driven less by architecture than by which team had capacity to validate their own service after cutover.

Service discovery was the load-bearing decision. Choosing Consul over cloud-native resolution was more work upfront and the reason the workloads were movable at all. A service that resolves its dependencies through a cloud-specific mechanism is not portable; it is merely running.

Rollback had to stay real. A rollback plan that has never been executed is a hope. On every cutover the rollback path was exercised before the forward path, which is slow, unglamorous, and the reason nothing needed rolling back in anger.

Outcomes

Zero downtime across all migrated workloads
Standardized migration playbooks adopted by other business units
Awarded “Migration Hero” recognition for execution of zero-downtime critical workload cutover

Reflection

Tokopedia was an important engagement for what it taught about scale and operational discipline. Zero downtime at e-commerce scale isn’t achieved by being careful — it’s achieved by designing for failure, validating rollback before you need it, and executing cutovers with enough observability that you know within minutes if something is wrong.

The “Migration Hero” award was recognition from the client, but the real value was the pattern: detailed runbooks, pre-validated rollbacks, and the discipline to abort and rollback rather than push through when signals were unclear.