We received an emergency notice from our current IDC (Internet Data Center) regarding the termination of their services due to aging server infrastructure and business restructuring.<\/p>\n
As a result, we need to migrate all data from our current server environment to a new one within a tight two-week window, and we are requesting your support for this transition.<\/p><\/blockquote>\n
This essentially meant it was a critical situation: “Once the migration deadline passes, the existing server environment will be forcibly shut down and deleted, rendering the website and all associated resources completely inaccessible.”<\/p>\n
<\/p>\n
\u2460 Analysis of Old Server Environment and Active Services, Migration Preparation<\/h2>\n
In response to this emergency, our company developed the following plan and proceeded with the server migration work.<\/p>\n
Typically, before a server migration, we identify the following information via the web console provided by the IDC:<\/p>\n
- \n
- Server Configuration (Server region, OS version, IP address, DNS, CPU, memory, disk, network bandwidth, etc.)<\/li>\n
- Resource Availability (Databases, SSL, CDN, domains, etc.)<\/li>\n<\/ul>\n
However, the old server environment in this case was unique, and the web console was inaccessible. Therefore, we conducted thorough hearings with the client (and their development engineers).<\/p>\n
As a result, we determined that the system is a PHP-based UGC (User-Generated Content) site for a specific industry, featuring WeChat Official Account integration and online payment functions.<\/p>\n
<\/p>\n
Investigation Results of the Old Server Environment<\/h3>\n
Through further detailed investigation, we gained an understanding of the approximate configuration of the website and server environment.<\/p>\n
\n\n
\n Category<\/span><\/td>\n Item<\/span><\/td>\n Configuration Details<\/span><\/td>\n<\/tr>\n \n Server Environment<\/td>\n OS<\/td>\n CentOS 7.9.2009<\/td>\n<\/tr>\n \n CPU<\/td>\n 4core<\/td>\n<\/tr>\n \n Memory<\/td>\n 8GB<\/td>\n<\/tr>\n \n System Disk<\/td>\n 40GB<\/td>\n<\/tr>\n \n Data Disk<\/td>\n 200GB<\/td>\n<\/tr>\n \n Network Bandwidth<\/td>\n 10Mbps\uff08Single line\uff09<\/td>\n<\/tr>\n \n Software Environment<\/td>\n Web Server<\/td>\n Nginx 1.24<\/td>\n<\/tr>\n \n Database<\/td>\n MySQL 5.7.44<\/td>\n<\/tr>\n \n Programming Language<\/td>\n PHP 7.4<\/td>\n<\/tr>\n \n Cache<\/td>\n Redis 6.2<\/td>\n<\/tr>\n \n File Transfer<\/td>\n FTP\uff08vsftpd\uff09<\/td>\n<\/tr>\n \n Management Tool<\/td>\n phpMyAdmin 5.1<\/td>\n<\/tr>\n \n WAF<\/td>\n ModSecurity<\/td>\n<\/tr>\n \n SSL Certificate<\/td>\n Available<\/td>\n<\/tr>\n \n Control Panel<\/td>\n Pagoda Panel\uff08\u5b9d\u5854\u9762\u677f\uff09<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/p>\n
\u2461 Log Into the Old Server Environment via SSH Tool (Xshell)<\/h2>\n
Our engineers attempted to log into the old server via SSH using Xshell, but the connection could not be established. Furthermore, the server was inaccessible even via local CMD commands (TCP\/IP).<\/p>\n
Upon investigation, it was discovered that the network provider used by the IDC server room had withdrawn, leaving only the China Mobile network active.<\/p>\n
Ultimately, we prepared a temporary “Relay Server (Linux Jump Box)” utilizing the China Mobile network. By first connecting to this relay server via Xshell and then executing the ssh root@127.0.0.1<\/span> command, we successfully established a connection to the old server.<\/p>\n
# <\/span>ssh conntect old linux server\r\nssh root@192.168.1.2\r\n# write old server 192.168.1.2 pwd<\/span><\/code><\/pre>\n<\/p>\n
\u2462 Backup of the Old Server Environment (Programs + Database)<\/h2>\n
We connected to the old server via the relay server and compressed\/packaged the server data, program source code, and database.<\/p>\n
First, we verified the directory structure and capacity of both the system and data disks to determine the scope and total size of the migration.<\/p>\n
# Display disks<\/span>\r\n[root@MyCloudServer ~]# df\r\n# List directories<\/span>\r\n[root@MyCloudServer ~]# ls \/path\/to\/directory\r\n# Check CPU information<\/span> \r\n[root@MyCloudServer ~]# ls lscpu\r\n# Back up all databases<\/span>\r\n[root@MyCloudServer ~]# mysqldump -u[username] -p --all-databases | gzip > \/path\/to\/backup_file.sql.gz\r\n# Back up a single database<\/span>\r\n[root@MyCloudServer ~]# mysqldump -u[username] -p[password] [database_name] > \/path\/to\/backup_file.sql\r\n<\/code><\/pre>\n<\/p>\n
\u2463 Bulk Data Transfer From the Old Server Environment to the Relay Server<\/h2>\n
Another challenge was that the old server lacked a dedicated administrator responsible for regular backups and monitoring.<\/p>\n
Furthermore, since the client utilized a low-cost local IDC service rather than a major cloud platform like Alibaba Cloud or AWS, security and operational efficiency had not been a primary consideration.<\/p>\n
As a result, the server’s backup capabilities were insufficient; although the website’s program volume totaled 160GB, the available backup capacity was only 40GB. To address this, we implemented a batch processing approach, migrating data according to the following priorities:<\/p>\n
- \n
- Package PHP source code and MySQL databases, then transfer them to the verification server.<\/li>\n
- Batch package large files (such as images) and transfer them.<\/li>\n
- Migrate website data and server logs together.<\/li>\n
- Package the entire server configuration\u2014including Nginx, MySQL, and PHP settings\u2014for a complete transfer.<\/li>\n<\/ol>\n
# Transfer the compressed package<\/span>\r\n[root@MyCloudServer ~]# scp \/local\/path\/backup.tar.gz username@remote_host:\/remote\/path\/\r\n# Transfer a directory<\/span>\r\n[root@MyCloudServer ~]# scp -r \/local\/directory\/ user@remote_host:\/remote\/path\/\r\n<\/code><\/pre>\n<\/p>\n
\u2464 Data Integrity Verification and Backup<\/h2>\n
Since the IDC provided only a single China Mobile line, we experienced drops in transfer speeds and frequent disconnections during large-scale data downloads.<\/p>\n
As a result, we implemented the following measures:<\/p>\n
- \n
- Conducted a detailed audit of the website’s program components and prioritized them by transfer size and importance.<\/li>\n
- Maintained continuous monitoring of the data transfer status.<\/li>\n
- Performed multiple backup cycles to cross-reference and verify data consistency.<\/li>\n<\/ul>\n
Furthermore, to prevent data loss, we established a temporary test environment on the relay server to verify data integrity. We paid particularly close attention to potential data gaps or character encoding issues during database transfers caused by the unstable connection.<\/p>\n
After approximately three days of work, we successfully completed the full migration from the old server to the relay server. We then confirmed the data integrity and normal website functionality within the test environment.<\/p>\n
Following this, we designed and built the new production server environment. After performing image data optimization (removing duplicates, compression, and deleting unused assets), we migrated the data to the new environment for final production release.<\/p>\n
Through these steps, the client was able to successfully overcome the imminent crisis of their service being shut down.<\/p>\n
<\/p>\n
Side Note: Why Do Sudden IDC Service Shutdowns Occur?<\/h2>\n
![\"\"](\"https:\/\/beyond-shenzhen.cn\/wp-content\/uploads\/2025\/09\/website-data-migration_img1.webp\")
<\/p>\nThe IDC originally used by this client was a small-scale, local IDC within China.<\/p>\n
In principle, operating an IDC involves massive overhead costs, such as rack leasing, electricity, bandwidth fees, hardware procurement, maintenance, and labor.<\/p>\n
However, global cloud platforms\u2014led by giants like Alibaba Cloud\u2014now offer services at such low prices that small-scale IDCs can no longer compete.<\/p>\n
As a result, it appears the IDC in this case, having lost its competitive edge, was forced to abruptly terminate its services.<\/p>\n
<\/p>\n
Summary<\/h2>\n
When contracting or utilizing a new server, we recommend selecting a highly reliable IDC or a global cloud platform.<\/p>\n
In particular, for projects requiring online payments or high levels of data security, the following global cloud platforms are most suitable:<\/p>\n
- \n
- Alibaba Cloud: Widely used across China and worldwide.<\/li>\n
- AWS: Possesses an extensive track record in Japan, North America, and Europe.<\/li>\n<\/ul>\n
These providers ensure stable access, network redundancy, and data security through their globally distributed IDCs.<\/p>\n
For needs such as corporate digitalization, overseas expansion, and cross-border trade, cloud platforms with global capabilities offer a significant advantage.<\/p>\n
<\/p>\n
Related Services<\/h3>\n