How a Hangzhou Gift Shop Moved to the Cloud in 12 Days: A Step-by-Step Migration Story

Cloud migration is rarely a clean, linear process. It's messy, full of surprises, and often happens under pressure. But when it works, it can transform a business. This is the story of a Hangzhou-based online gift retailer that had to move its entire IT infrastructure to the cloud in under two weeks—or face losing its data center lease.

The Business Problem: A Lease Expiring at the Worst Time

The company, founded in 2006, ran a popular custom gift platform. By late 2014, they knew their physical data center contract was ending in February 2015. What made it tricky? Valentine's Day—their biggest sales peak of the year—falls right in the middle of that timeline. They needed to migrate before the rush, and they needed it done fast.

Their existing setup was typical for a mid-sized e-commerce operation: three racks in a telecom data center, about 40 Dell R410 servers (a couple with 16 cores and 96GB RAM for virtualization), and a 200Mbps dedicated line. They had a CDN for product images, Nginx and Varnish for caching, and a mix of Java, PHP, and Python applications. MySQL handled the database, with Redis in front for caching. Image storage ran on NFS, holding over 2TB of data.

The Three Pain Points That Pushed Them to Cloud

Why move to the cloud at all? The company's leadership saw three major issues with their on-prem setup:

• Cost of manpower: They had a team of four ops people just to keep the lights on. That's expensive, especially for a mid-sized retailer.
• No 24/7 monitoring: When something broke at 2 a.m., nobody was watching. Alerts went unanswered, and downtime cost money.
• Scaling limitations: Adding capacity meant buying hardware, racking it, and configuring it. That took weeks, not minutes.

The company decided to hand the whole thing over to a cloud consulting firm. The deal included architecture design, migration, and ongoing 24/7 monitoring and support. The client's in-house ops team would play a supporting role.

Three Challenges That Made This Migration Hard

Most cloud migrations have at least one headache. This one had three.

1. A Brutal Timeline

The contract was signed in late December. The data center lease expired in February. That left just two weeks to complete the migration, test everything, and go live. And they wanted two extra weeks as a buffer before Valentine's Day traffic hit.

2. A Zoo of Technologies

There were over ten business systems running on a stack that included Nginx, Varnish, Tomcat, PHP, Python, Redis, and MySQL. Each had its own quirks and dependencies. Migrating them all without breaking anything was like juggling chainsaws.

3. Zero Documentation

Here's the kicker: after eight years of running this system, the company had almost no documentation. A few scattered architecture diagrams, no runbooks, no config files. Hostnames were inconsistent, firewall rules were a mess, and at one point they couldn't even log into their own switch because nobody remembered the password.

The Seven-Step Migration Plan

Despite the chaos, the team pulled it off. Here's how they did it, step by step.

Step 1: Project Kickoff

On January 5, 2015, the team—one ops lead, two architects, a DBA, and three ops engineers—drove to Hangzhou. Their first day was all about alignment: defining roles, setting up a contact list, and locking in a 12-day project plan.

Step 2: Architecture Review and Cloud Design

During the next two days, they mapped the existing systems and designed the cloud architecture. The new setup had some key differences:

• SLB for load balancing: Instead of pointing DNS at multiple Nginx servers, they put an SLB in front. This made the front end more flexible and scalable.
• TCP-layer SLB for performance: They chose TCP-level load balancing over HTTP-level because it handles far more concurrent connections—millions vs. tens of thousands.
• Pay-as-you-go bandwidth: Their old 200Mbps dedicated line cost about ¥240,000 a year. On the cloud, they got 1Gbps peak BGP bandwidth and only paid for what they used. Massive savings.
• Managed RDS for MySQL: They replaced the manually managed MySQL master-slave setup with Alibaba Cloud's RDS. That meant automatic failover, backups, and monitoring—no more babysitting replication.

Step 3: Migration Plan

While the architecture was being designed, they also planned the actual data and application migration. The resource list included 23 ECS instances, 2 RDS databases, and 1 SLB. Most servers were 4-core/8GB or 2-core/4GB.

One of the trickiest parts was moving 2TB of product images. The images were mostly small files, and the cloud disks at the time maxed out at 1TB each. So they used LVM to combine four 1TB disks into a single 4TB logical volume. LVM also gave them a 20-40% I/O boost, which helped with the 3 million daily page views.

For the actual data transfer, they used Rsync for incremental file sync. But because the data had to go over the public internet, it took over a week. They started that early to avoid delaying the whole project.

Step 4: Migration Execution

Deploying 23 servers with Nginx, PHP, Tomcat, Redis, and Varnish sounds daunting, but automation made it quick. They created a base image after tuning one server, then cloned it to the other 22. That took about 30 minutes. Software installation was handled with Ansible playbooks, which pushed install scripts from their internal GitLab to the new machines in under five minutes.

But then came the painful part: debugging every configuration without proper documentation. Three ops engineers, along with the client's dev team, spent a full day and night fine-tuning all the application code and settings.

Two things saved them from disaster:

• Domain registration first: They made sure the domain was filed with the Chinese authorities before pointing it to Alibaba Cloud. If they'd done it the other way, the domain would have been blocked.
• Image templates: By creating a golden image with all the security and performance tweaks, they avoided repeating manual setup on each server.

Step 5: Testing

From January 9 to 11, the client's testing team ran functional and performance tests. This was their chance to catch anything that didn't work before the big switch.

Step 6: Cutover

The cutover happened on January 13-15. Because there were multiple databases and they couldn't do a live migration, they chose a brief downtime. They announced the maintenance window, shut down the old systems, moved the final data, and switched DNS to point to the new cloud IPs.

But that wasn't the end. DNS propagation can take up to 10 minutes on the authoritative side, and users' local DNS caches could point to the old site for hours. To handle that, they set up a 302 redirect on the old Nginx servers. Anyone hitting the old IP got bounced to the new cloud site automatically.

Step 7: Handover and Ongoing Monitoring

After the migration, they delivered over 30 documents—architecture diagrams, runbooks, troubleshooting guides, resource lists, you name it. Then they moved into a 24/7 monitoring and support phase, which is what the client really wanted.

Costs Before and After

The table below shows the cost comparison between the old IDC setup and the cloud solution:

• Before: 4 ops engineers, 40 physical servers, 200Mbps bandwidth, manual MySQL management.
• After: 23 ECS instances, 2 RDS, 1 SLB, pay-as-you-go bandwidth, and no ops staff needed.

In the first year, the client kept one ops person for odd jobs. By the second year, even that role was gone. The cloud had made their entire ops team redundant.

Lessons for Anyone Planning a Cloud Migration

This case study isn't just about one company. It's a blueprint for anyone moving from physical infrastructure to the cloud. Here are the takeaways:

• Start early on data transfer. If you have terabytes of small files, Rsync over the internet takes time. Kick it off as soon as you can.
• Automate everything. Use base images and configuration management to spin up servers quickly and consistently.
• Don't forget DNS and domain registration. Get your domain filed before you point it to the new provider. And plan for DNS cache lag—use redirects if needed.
• Design for the cloud, not just lift-and-shift. The real savings came from using managed services like RDS and SLB, not from renting the same virtual machines.
• Documentation matters. The lack of it nearly derailed this project. Spend time creating runbooks, even if it feels like a chore.

Cloud migration is never just a technical exercise. It's a business decision that affects your team, your budget, and your ability to scale. This Hangzhou company learned that the hard way—but they came out the other side with a faster, cheaper, and more reliable infrastructure. And that's a pretty good Valentine's gift.