Migration Proposal · Pre-Sales

From Alibaba Cloud to Tencent Cloud

Why managed database services beat self-built, how we cut over with little or no downtime, how we connect the two environments, and exactly which Tencent Cloud service and migration tool replaces each component you run today.

ScopePostgreSQL · MongoDB · Redis · OSS

ApproachCold & hot cutover

ConnectivityDirect Connect / VPN / Internet

Prepared byTencent Cloud Solution Team

01

Agenda

What we will cover

Four topics, moving from the strategic case for managed services down to a concrete per-product migration plan for your estate.

1

Managed vs. Self-Built

Why TencentDB outperforms self-managed databases — with measured Redis and MongoDB evidence.

2

Migration Modes

Cold (downtime) and hot (smooth) migration — architecture, flow and trade-offs.

3

Network Planning

Direct Connect, VPN and public internet — when each is the right transport.

4

Your Migration Plan

Service mapping, tooling deep-dive (DTS, go2tencentcloud, COS, CMG) and a per-product plan.

Your current estate. Primary database PostgreSQL; secondary MongoDB; caching on Redis; file and object storage on OSS. Topic 4 maps each of these to a target service, a migration tool and a recommended cutover mode.

02

01

Why Managed Services Beat Self-Built

A self-built database is not just software you install — it is an availability architecture, a backup system, a monitoring platform and a kernel team that you have to build and staff yourself.

03

Topic 1 · Overview

Six dimensions where managed pulls ahead

These are the axes on which we will compare, and the same axes the Redis and MongoDB evidence on the next pages is measured against.

Availability

Replica set and sharded cluster out of the box
Automatic failover in seconds
Multi-AZ deployment, cross-region DR instances
Failover keeps the same endpoint

Reliability

Distributed architecture, multiple live copies
MongoDB: 99.9996% data reliability
Automatic full + incremental backup
Point-in-time recovery within the window

Elasticity

Thousands of instances in minutes
Online scaling with no application rework
Standard → cluster upgrade in place
Self-built IDC provisioning can take a month

Intelligent O&M

DBbrain: 30+ metrics, auto inspection
Index recommendation, SQL throttling
Slow-log, big-key and hot-key analysis
One-click kill for fast recovery

Kernel Capability

Dedicated kernel team fixes bugs fast
Enterprise features per workload
Self-built waits on community releases
Kernel engineers are costly to retain

Security & Cost

VPC isolation, security groups, audit logs
Automatic version and CVE patching
20%+ cheaper than comparable self-built
No hidden O&M headcount cost

The pattern. Self-built gives you the engine. Managed gives you the engine plus the availability, backup, observability and optimization systems around it — each of which is a project in its own right.

04

Topic 1 · Overview

What you stop having to build

The same database workload, split by who owns each layer.

Customer-operated Tencent Cloud-operated

05

Topic 1 · Overview

Managed vs. self-built, by database category

The gap is real for every engine, but it shows up in a different place depending on what the database is for.

Category	Your engine	Where self-built hurts most	What managed changes
Relational OLTP	PostgreSQL	HA needs streaming replication plus a failover controller you build. PITR depends on disciplined WAL archiving. Major-version upgrades mean planned downtime.	Automatic failover on a fixed endpoint, automated backup with point-in-time recovery, read replicas on demand, DBbrain slow-SQL and index advice.
Document NoSQL	MongoDB	Replica sets and sharding must be built and rebalanced by hand. Logical backup only, which is slow. Library/table-level restore is error-prone.	Replica set and sharded cluster managed, 99.9996% data reliability, physical + logical backup, batch table-level rollback, million-table kernel optimization.
Cache In-memory	Redis	Hot keys saturate a single node and only application-layer work can fix it. Native Cluster scaling migrates key-by-key, so a big key blocks the main thread.	Proxy-based read/write split at 4× community throughput, slot-level online scaling with connections preserved, cross-AZ auto failover and failback.

Common thread. Self-built forces you to solve availability, scaling and observability separately for every engine. Managed services solve them once, consistently, behind one console and one API.

06

Topic 1 · Overview

The cost conversation, honestly

Managed is usually cheaper on comparable hardware — and where raw hardware wins on paper, elasticity and operational load decide it.

20%+

Cheaper than comparable self-built on standard instance types (MongoDB)

Minutes

To provision, versus up to a month for IDC hardware

0

Dedicated DBA headcount required to run HA and backup

30+

Monitoring items available in DBbrain out of the box

Self-built total cost

Compute, storage and network for every node
Idle headroom bought up front for peak traffic
Engineering time to build HA, backup, monitoring
On-call rotation and senior DBA retention
Opportunity cost: the platform team is not building product

Managed total cost

Instance price, scaled to actual demand
Scale up for a campaign, scale back down after
HA, backup and monitoring included
Kernel team and DBbrain expertise included
Team time goes back to the application

Where self-built can look cheaper. With high-IO instance types on local disks, a self-built MongoDB can price below managed. But those SKUs have fixed disk sizes and few available shapes — they generally only suit large, stable instances, and you give up elastic scaling entirely.

07

Topic 1 · Evidence · Redis

Redis: measured throughput vs. self-built

Benchmarks from the TencentDB for Redis product team, comparing the high-performance edition against a competitor's enhanced tier and against self-built Redis.

TencentDB for Redis (high-performance) Competitor (enhanced tier) Self-built Redis

4.3×

Standard single-replica throughput versus self-built — 560K vs 131K QPS

2.5×

Five-replica read-enabled throughput versus self-built — 1.66M vs 654K QPS

400K+

QPS on a single high-performance node, so hot keys need no application redesign

Online scaling. Native Redis Cluster rebalances key-by-key: a large key blocks the main thread, a transfer over 15 seconds can fail the cluster, Lua is not migrated, multi-key commands error, and redirection can loop. TencentDB ships the slots as an RDB snapshot, catches up with AOF, then performs a single failover to switch ownership — client connections are never dropped.

08

Topic 1 · Evidence · MongoDB

MongoDB: self-built vs. TencentDB, point by point

Condensed from the TencentDB for MongoDB product comparison.

Dimension	Self-built MongoDB	TencentDB for MongoDB
Availability	Build the cluster yourself; span AZs and keep connectivity stable yourself; DR depends on application-level sync or third-party tools.	Replica set and sharded cluster provide HA; multiple detection mechanisms with automatic failover; multi-AZ and DR instance deployment.
Reliability	You guarantee service and hardware stability; backups maintained manually.	Distributed multi-node architecture delivering 99.9996% data reliability; automatic backup prevents data loss.
Deployment	Buy hardware or VMs, deploy, configure the cluster. Rescaling means stopping hosts and services — long interruption.	Provision on demand in minutes; one-click scaling; easy node management for read/write split and AZ planning.
Cost	Extra O&M cost up front plus possible hardware maintenance.	Price advantage over both IDC-built and VM-built deployments.
Intelligent O&M	Extract metrics, maintain the data pipeline and build the monitoring platform yourself; no mature alerting; tuning without expert support.	DBbrain plus Cloud Monitor: full metric coverage, slow-log analysis, custom alerts, real-time diagnosis, index recommendation, SQL throttling, Mongostat/Mongotop integration.
Backup & restore	Design your own backup scheme; logical backup only, so it is slow; cluster and table restore are fiddly and error-prone.	Automatic logical and physical backup; full plus incremental; batch table-level rollback; point-in-time recovery inside the window.
Security	Build network protection yourself; export and analyse audit logs yourself; manage versions and upgrades manually.	VPC access control; full audit capability; automatic version upgrade and rapid vulnerability patching.
Kernel	Stock open-source build with no workload-specific optimization.	Million-table scenario support; geoNear query optimization; 200K+ QPS per shard.

09

Topic 1 · Evidence · MongoDB

MongoDB price comparison, like for like

Monthly price in USD, three nodes, NVMe SSD throughout — managed instance versus the equivalent built on VMs.

Configuration	Spec	Disk	TencentDB USD/month	Self-built on VM USD/month	Difference
Replica set · small	4C8G vs S5.LARGE8	400 / 500 GB	$261	$395	34% cheaper
Replica set · medium	24C64G vs S5.4XLARGE64	2,200 / 2,500 GB	$1,775	$2,101	16% cheaper
Replica set · large	24C128G vs IT5.8XLARGE128	3,200 / 3,570 GB	$3,119	$2,372	high-IO SKU wins
Sharded cluster	24C64G vs S5.4XLARGE64, 2 shards	2,200 / 2,500 GB	$3,549	$4,420	20% cheaper

Standard shapes

On comparable standard instance types, managed MongoDB is 20%+ cheaper

High-IO shapes

Local-disk high-IO SKUs can beat managed on price, but disk size is fixed and few shapes exist — usually only large instances

The deciding factor

PaaS elasticity remains a major advantage: scale for peak, scale back after, no host downtime

Prices converted from CNY list price at 6.75 CNY/USD and rounded to the nearest dollar; indicative only, and subject to exchange rate movement and regional list-price differences.

10

02

Cold and Hot Migration

Two cutover strategies. One trades a maintenance window for simplicity; the other trades complexity for near-zero business impact.

11

Topic 2 · Modes

Cold vs. hot migration at a glance

Same six-step spine, different risk profile and different demands on the application.

Choosing. Cold migration suits a small, simple estate that can tolerate a window — it is technically simpler and the process is clear. Hot migration suits a large, complex, traffic-heavy estate that cannot stop, but it requires a clear service architecture and detailed dependency analysis first.

12

Topic 2 · Cold Migration

Cold migration architecture

One decisive cutover inside a maintenance window: everything moves together.

Pros

Highly generic — works for almost any stack
Simple process, clear workflow
Low demands on the application architecture
Suited to small scale, simple business, low traffic

Cons

Downtime length is hard to predict and control
More rollback complications once committed
Requires an agreed window when downtime is acceptable
All risk concentrated in one event

13

Topic 2 · Hot Migration

Hot migration architecture

Both environments serve live traffic while weight shifts gradually and databases cut over one application at a time.

Pros

Low business impact; users mostly unaware
Flexible — pause or roll back at any weight
Rollback is cheap while both sides stay in sync
Suited to large scale, complex, high-traffic estates

Cons

May run for a long time overall
High demands on application architecture clarity
Direct Connect bandwidth pressure from cross-environment traffic
Migration sequencing and granularity need careful control

Operational watch-points. Early: analyse coupling and call relationships in detail and size the cross-access bandwidth. Mid: monitor crossing traffic and Direct Connect utilization to avoid saturating the link. Late: after cutover, confirm no configuration still points at the source database.

14

03

Network Planning

Direct Connect, VPN or public internet — the transport decision shapes migration duration, cost and risk.

15

Topic 3 · Connectivity

Three ways to connect the two environments

All three can carry migration traffic; they differ in latency guarantee, bandwidth ceiling and cost.

16

Topic 3 · Connectivity

Which transport, and when

Advantages, drawbacks and the scenario each option is actually built for.

	VPN	Direct Connect	Public internet
Advantages	Fast to provision; high security, with traffic encrypted using IKE pre-shared keys.	Guaranteed low latency; dedicated link with high security; large bandwidth with no theoretical ceiling; supports NAT on the gateway to resolve address conflicts.	Fast to provision, no additional line cost.
Drawbacks	Network quality depends on the public internet.	Dedicated line cost, plus lead time to provision.	Latency and reliability are lower than Direct Connect.
Best for	Modest data volume with high security requirements.	Large migrations at TB or PB scale.	Smaller migrations at GB scale.
Data scale	GB – low TB	TB – PB	GB
Latency	Best-effort	Guaranteed	Variable

Recommendation for this migration. Use Direct Connect as the primary path for database replication and hot-migration crossing traffic, where guaranteed latency and bandwidth matter and volumes are large. Keep a VPN as the backup path for control-plane and management access. Use the public internet only for the bulk OSS→COS object copy, which is throughput-tolerant, restartable and easy to parallelise. Also confirm the source and target CIDR plan early — Direct Connect gateway NAT resolves address overlap if the two VPC ranges collide.

17

04

Your Migration Plan

Mapping your Alibaba Cloud services to Tencent Cloud targets, with the migration tool and cutover mode for each.

18

Topic 4 · Mapping

Service mapping for your estate

Your four in-scope components, their Tencent Cloud targets and the tool that moves each one.

Category	Alibaba Cloud today	Target Tencent Cloud service	Migration tool	Recommended mode
Database Primary	RDS for PostgreSQL	TencentDB for PostgreSQL	DTS — structure, full and full + incremental	Hot per-application cutover
Database Secondary	ApsaraDB for MongoDB	TencentDB for MongoDB	DTS — full + incremental (oplog)	Hot or cold if the window allows
Cache	ApsaraDB for Redis	TencentDB for Redis	DTS, or rebuild cache from source of truth	Warm dual-write then drain
Storage	OSS	Cloud Object Storage (COS)	MSP / COS Migration	Hot bulk copy then incremental
Compute if in scope	ECS	Cloud Virtual Machine (CVM)	MSP, go2tencentcloud	Redeploy, or whole-machine online migration
File if in scope	NAS / CPFS	Cloud File Storage (CFS)	Filetruck	Bulk copy then incremental sync

Migration Service Platform (MSP) is the umbrella console for this work: resource scanning, a resource selection and mapping reference, resource provisioning, object storage migration, batch database migration helpers, cutover tooling and big-data validation — with coverage for all mainstream cloud providers.

19

Topic 4 · Tooling

DTS: the engine behind the database moves

Data Transmission Service handles PostgreSQL, MongoDB and Redis replication from Alibaba Cloud sources.

Capabilities

Supports self-built sources and other clouds including Alibaba Cloud and AWS
Nine source engine families — MySQL, Redis, MongoDB, Percona, SQL Server, TDSQL and PostgreSQL
Structure-only, full, and full + incremental migration
Heterogeneous migration across engine types and versions
Resumable transfer after interruption
Built-in data consistency checking

Constraints to plan around

Base tables and views are migrated; functions, triggers and stored procedures are not — port these separately
Interdependent objects must migrate together or the task fails
Minimum source version requirements apply per engine
Validate application SQL against the target version before cutover

Cutover pattern for every database. Set the source read-only and kill long connections → wait for incremental lag to reach zero and the consistency check to pass → stop the DTS task and flush logs on both sides → enable read/write on the Tencent Cloud instance → repoint the application endpoint. Keep a reverse sync task configured so rollback stays cheap.

20

Topic 4 · Tooling

Key tools deep-dive — DTS and go2tencentcloud

Supported source-to-target pairs, sync topologies, measured throughput, and the host migration agent.

DTS — Data Transmission Service

Principle: source dump → load → binlog incremental sync & verify

Supported source → target

Source	Target
MySQL	MySQL, TDSQL-C, TDSQL MySQL, Percona
Aurora MySQL / PolarDB	TDSQL-C MySQL
PostgreSQL	PostgreSQL
MongoDB	MongoDB
Redis	Redis
SQL Server	SQL Server

Sync topologies

1:1 unidirectional · cascading · 1:N · N:1 · bidirectional · table-level

Performance reference

1 TB / 4 databases / 1,115 tables over Direct Connect: ~69 hours — full export 5 min, import 2 h 22 m, incremental 7 h 39 m, verification 1.5 days. Factors: data size, table complexity, bandwidth (max 60 MB/s), source and target specs.

go2tencentcloud

Online VM migration — the source machine stays running.

Supported OS

Linux: CentOS 5–8, Ubuntu 10–20, Debian 7–10, SUSE 11–15, openSUSE 42, Amazon Linux, RHEL 5–8, Oracle Linux 5–8
Windows: Server 2008–2022

Usage

# Environment check
sudo ./go2tencentcloud_x64 --check

# Execute migration
sudo ./go2tencentcloud_x64

Docs: cloud.tencent.com/document/product/213/65711

Stateful app caution. Self-hosted caches, long-lived connections and distributed clusters require special handling during migration — do not rely on whole-machine imaging alone for these.

21

Topic 4 · Tooling

Key tools deep-dive — COS smooth migration and CMG

Zero-downtime object storage cutover using origin pull, and the platform that orchestrates the whole migration.

COS smooth migration (zero downtime)

Step 1 · Full sync

Use the COS Migration tool. Data modified during the sync can cause inconsistency — run it multiple times with mtime traversal to minimize the gap.

Step 2 · Configure origin

After switching business to COS, enable origin pull (回源) in the COS console. When COS lacks a resource it fetches it from the source and stores it.

Step 3 · Traffic switch

Switch business reads and writes to COS. The source remains available as fallback while incremental data keeps syncing in the background.

CMG — Cloud Migration Platform

End-to-end visualization platform covering the entire migration lifecycle.

Auto discovery

Alibaba Cloud / Huawei / IDC full scan

Smart mapping

Auto-recommends Tencent Cloud specs

Batch provisioning

Simplifies parameters, less manual work

Dashboard

Real-time progress monitoring

Efficiency gain. Overall cycle drops from 1–2 weeks to 1–2 days. For every 100 resources, roughly 80% efficiency improvement.

22

Topic 4 · Per-Product Plan

Migration plan by product

Approach, key steps and rollback position for each component in your estate.

PostgreSQL → TencentDB for PostgreSQL

Mode: hot migration, cut over per application
DTS full + incremental sync of the whole instance
Pre-check functions, triggers and stored procedures — port manually, DTS does not carry them
Freeze writes only when lag and data gap both reach zero
Back up the source, run the consistency check, then switch reads and writes
Read/write split possible if the application supports it — cut reads first, then writes
Rollback: reverse sync keeps both sides consistent, so cost is low

MongoDB → TencentDB for MongoDB

Mode: hot migration; cold is acceptable if a window exists
DTS full backup plus real-time oplog incremental sync
Match replica-set or sharded topology on the target before sync
Verify document counts and index definitions after sync
Switch the connection string at cutover; endpoint stays stable afterwards
Gain on arrival: automatic backup, PITR, DBbrain index recommendation
Rollback: keep the source cluster live until validation passes

Redis → TencentDB for Redis

Mode: warm — dual-write, then drain the source
Cache can often be rebuilt from the source of truth instead of migrated
If persistence matters, use DTS to sync then verify key counts and TTLs
Size on measured QPS — high-performance edition reaches 400K+ QPS per node
Proxy gives automatic read/write split, so no application rework for hot keys
Warm the cache before shifting read traffic to avoid a miss storm
Rollback: repoint the client to the source cache; low risk

OSS → COS

Mode: hot — bulk copy first, then incremental catch-up
MSP / COS Migration performs the bulk transfer, parallelised by prefix
Run the bulk copy over the public internet to spare Direct Connect bandwidth
Re-run incremental passes until the delta is empty, then switch the write path
Verify object counts, sizes and ACL or permission mapping
Update application SDK endpoints and any CDN origin configuration
Rollback: keep the source bucket read-only but intact until sign-off

23

Topic 4 · Cutover

Database cutover approaches, and what customers actually pick

Two patterns, with the risk profile and adoption share observed across migration projects.

Approach	Write freeze	Inconsistency risk	Rollback risk	Business conditions	Share of cases
Cut reads and writes together	Low	Low	Medium	Database write freeze; no application changes needed	80% of customer cases
Cut reads first, then writes	Low	Low	Low	Database write freeze; application needs read/write splitting	20% of customer cases

Recommended for you

PostgreSQL: cut reads first if the application already splits read/write — lowest rollback risk. Otherwise cut together.
MongoDB: cut together; the write freeze is short once oplog lag is zero.
Redis: no freeze needed — dual-write and drain.
OSS: no freeze — incremental catch-up until the delta is empty.

Risk controls on every cutover

Reverse sync task configured before the switch
Consistency check must pass before enabling writes on the target
Source kept intact and read-only until sign-off
Source forwarding stays on after DNS switch to absorb cached and tail traffic
Monitoring and alarms live on both sides throughout

24

Topic 4 · Execution

Four phases from here to sign-off

The standard migration lifecycle, applied to your estate.

Next step. A migration survey workshop to complete the resource inventory and dependency map for PostgreSQL, MongoDB, Redis and OSS. That gives us measured data volumes and coupling detail, which in turn fixes the Direct Connect bandwidth, the batch order and the cutover windows.

25

Thank you

Questions & next steps

Happy to go deeper on any topic — benchmark methodology, network design, a per-application cutover sequence, or a detailed price comparison for your actual specifications.

Follow-upMigration survey workshop

DeliverableResource inventory & dependency map

ThenDetailed cutover schedule

26