Guide to Migrating Your Website from cPanel Hosting to DigitalOcean 2026

การย้ายเว็บไซต์จากโฮสติ้งแบบ shared ที่มี cPanel มาเป็น DigitalOcean Droplet คือการเปลี่ยนจากแผนบริการสำเร็จรูปมาเป็นเซิร์ฟเวอร์ที่ต้องดูแลเอง

Migrating a website from shared cPanel hosting to a DigitalOcean Droplet represents a shift from an off-the-shelf managed service to a self-managed server, offering both greater control and a different cost-to-resources model. This guide walks you through each step—from preparing your Droplet and migrating files and databases to executing a seamless DNS cutover—complete with a checklist and common pitfalls to watch out for.

Why Migrate from Shared Hosting to a Droplet

Shared hosting with cPanel is a popular choice for small to medium-sized websites because the hosting provider manages the operating system, applies security updates, and provides a ready-made control panel to install web applications, manage domains, handle email, and administer databases with just a few clicks. Website owners don't have to deal with server-level configuration at all. The common limitation of this model is that CPU and RAM resources are shared with other users on the same server, which can make performance inconsistent when traffic from neighboring sites spikes. Specialized customization—such as a specific PHP version, particular extensions, or complex cron jobs—is often constrained by each provider's policies. Moving to a Droplet means switching from a "flat-fee plan" model to leasing a virtual machine with full root access. CPU, RAM, and disk space belong exclusively to that website, not shared in the same way as shared hosting, and you can choose which stack to install, which versions, and what additional services you need. DigitalOcean's basic Droplets (Basic, shared CPU) start at 512 MiB RAM / 1 vCPU / 10 GB SSD / 500 GiB transfer for $4/month, scaling up to 4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer at $24/month for moderately-trafficked sites, with per-second billing, minimum 60 seconds or $0.01—whichever is higher (pricing as of July 2026—verify current rates on DigitalOcean's official pricing page). The significant trade-off is increased responsibility. Once you move to a Droplet, you or your development team must handle everything: OS and security patch updates, firewall configuration, installation and management of web and database servers, and backup systems—tasks that the shared hosting provider handled as part of your monthly fee. The decision to migrate isn't always "better" or "worse," but depends on whether your website and team are ready to take on server maintenance in exchange for greater control and often lower per-unit resource costs compared to shared hosting plans.

1. Shared hosting: provider manages OS/patches/control panel in exchange for shared resources with other users
2. Droplet: full root access, resources dedicated to your site, free choice of stack and versions
3. Basic Droplet pricing: from $4/month (512MiB/1vCPU/10GB) to $24/month (4GiB/2vCPU/80GB) — July 2026 rates
4. On a Droplet, you must handle security patches, firewall, backup yourself—tasks the provider covered before

Prepare Your Droplet and Install LEMP/LAMP Stack

Before creating a Droplet, assess the appropriate size based on your current site's traffic and resource usage on shared hosting. For a typical WordPress or CMS site with moderate traffic, a 2 GiB RAM / 2 vCPU / 60 GB SSD plan at $18/month, or 4 GiB RAM / 2 vCPU / 80 GB SSD at $24/month, is often sufficient to start. Smaller static sites or low-traffic blogs might start at 1 GiB RAM / 1 vCPU for $6/month (Basic shared CPU pricing as of July 2026). For users in Thailand, the sgp1 (Singapore) region offers the lowest latency, with blr1 (Bangalore) as a second choice. First-time DigitalOcean users receive $200 in free trial credits valid for 60 days post-signup—enough to test your migration before committing to paid service. Get $200 Free Credit → Once your Droplet is created (Ubuntu 24.04 LTS recommended), the first step is to set up SSH key authentication instead of password login using ssh-keygen -t ed25519 -C "[email protected]" on your local machine, then select this public key when provisioning the Droplet. Next, log in via ssh root@your_droplet_ip and update the system before installing anything with apt update && apt upgrade -y. For your web stack, you have two main approaches that closely mirror your old cPanel environment: LEMP (Linux, Nginx, MySQL, PHP) installed via apt install nginx mysql-server php-fpm php-mysql -y, or LAMP (Linux, Apache, MySQL, PHP), which behaves more like the Apache on your old cPanel and can be installed with apt install apache2 mysql-server php libapache2-mod-php php-mysql -y. Your choice depends on how heavily your site relies on .htaccess rewrite rules, since Nginx doesn't read .htaccess files directly and requires you to translate rules into server blocks yourself. After installing your stack, immediately set up a basic firewall with ufw: ufw allow OpenSSH, ufw allow 'Nginx Full' (or 'Apache Full' if using LAMP), then enable it with ufw enable. Do this before you start migrating real files from your old site, so your new server has baseline security in place before any incoming traffic.

• Choose Droplet size by current traffic: small sites 1GiB/$6, typical CMS 2-4GiB/$18-24 per month (July 2026)
• For Thailand-based users, choose sgp1 (Singapore) region first, blr1 (Bangalore) second
• Set up SSH key before going live—replace password login from the moment you create the Droplet

Migrate Website Files and Database

Begin by backing up all website files from your old hosting provider. If your shared host offers SSH access (some providers do), you can compress your web folder with tar -czvf public_html.tar.gz public_html/ and transfer it directly to your new Droplet using scp user@oldserver:/home/user/public_html.tar.gz . Alternatively, for incremental syncing (useful for large file sets that you'll sync multiple times before final cutover), use rsync -avz ./public_html/ user@newserver:/var/www/yourdomain/, which will copy only changed files in subsequent runs—saving time near your actual cutover date. If your old host doesn't offer SSH, use cPanel's file manager to create a zip, then download via FTP/SFTP. For your MySQL/MariaDB database, export everything on the old server using mysqldump -u user -p dbname > backup.sql, then transfer the file to your new Droplet with scp backup.sql user@newserver:/tmp/, and import it back with mysql -u user -p newdbname < backup.sql. For sites with multiple databases, handle them one at a time and verify that the dump file size and table count match the source before discarding backups. After files and database are in place, update your application's config files to point to the new database. For WordPress, that's wp-config.php; for modern frameworks, it's often .env. Set proper permissions so your web server can access the files correctly: chown -R www-data:www-data /var/www/yourdomain and find /var/www/yourdomain -type d -exec chmod 755 {} \; for directories, plus find /var/www/yourdomain -type f -exec chmod 644 {} \; for files. Test the site through the Droplet's IP directly or via /etc/hosts to confirm everything works before you switch DNS. Run a final sync of files and database a few hours (or even minutes) before your actual DNS cutover to pull the latest changes that may have occurred during your preparation phase. This is especially important for sites with ongoing data updates—like e-commerce or membership systems—to minimize data loss during the transition.

• Compress and transfer files using tar+scp or incremental sync with rsync -avz
• Export database with mysqldump -u user -p dbname > backup.sql, import with mysql -u user -p newdbname < backup.sql
• Update app config files (wp-config.php, .env) to point to the new database on your Droplet
• Set permissions with chown -R www-data:www-data and chmod 755/644
• Sync files and database one more time just before your actual DNS cutover to avoid data loss

Migrate DNS with Zero Downtime (TTL/Cutover)

The most overlooked but critical step to minimizing downtime is preparing your DNS well in advance. Lower the TTL (Time To Live) on your relevant DNS records—especially the A record for your main domain and www—to a low value like 300 seconds (5 minutes) at least 24–48 hours before your actual switch. Worldwide DNS resolvers cache records according to their TTL; if your current TTL is high (hours or days), changes will propagate slowly to all users. Before switching DNS, thoroughly test your site on the new Droplet by editing your local /etc/hosts file—add a line like YOUR_NEW_IP yourdomain.com www.yourdomain.com—to force your browser to hit the new server directly. Test login, contact forms, shopping carts (if present), and critical pages fully before letting real users see anything. When you're confident, log into your DNS provider (DigitalOcean DNS or your existing registrar) and update your A record to point to your new Droplet's IP. After saving, verify the propagation with dig yourdomain.com +short from multiple machines/networks, or use dig +trace yourdomain.com for a detailed resolution path. Results may vary temporarily across locations because some ISP resolvers still hold the old record until the original TTL expires. The critical window is the 24–48 hours after you switch DNS: keep your old server running (don't shut it down or cancel the service immediately) to handle users whose resolvers are still sending requests to the old IP during transition. If your site processes updates—orders, memberships, etc.—during this window, plan to sync any new data back to the new server. Once you're confident all traffic has moved to the new Droplet and sufficient time has passed, restore your TTL to a normal value (3600 seconds or higher) and finally cancel your old hosting.

• Lower your A record's TTL to roughly 300 seconds at least 24–48 hours before your actual switch
• Test your site on the new Droplet via /etc/hosts before switching DNS to verify all functions work
• Check DNS propagation with dig yourdomain.com +short or dig +trace

Post-Migration Checklist

One thing that surprised us: after switching DNS and confirming your site runs on the new Droplet, verify these items to call the migration truly complete. Start with SSL certificates: your old certificate won't work on the new server, so issue a new one via Let's Encrypt using Certbot, e.g., certbot --nginx -d yourdomain.com -d www.yourdomain.com (or --apache for LAMP), which also sets up automatic renewal. Next, cron jobs from your old cPanel won't migrate automatically. Tasks like automated backups, daily email summaries, or temp file cleanup won't exist on your Droplet unless you recreate them. Reference your old cPanel cron list and set them up again using crontab -e before you shut down the old service. Email for your domain is a separate concern, since MX records don't move with your A record automatically. If your old hosting provided domain email (e.g., [email protected]), decide whether to run a mail server on your Droplet yourself (which has deliverability complexities) or move to a separate email service and point your MX records there instead. Test critical functions one more time on your live domain after DNS has fully propagated—contact forms that send email, login/signup systems, and payment pages (if applicable). Set up DigitalOcean's free Monitoring (CPU/RAM/Disk/Bandwidth metrics and 1 free Uptime Check per account) to know immediately if your new server has problems. Finally, enable DigitalOcean's free Cloud Firewall (no added cost) on top of the ufw you already configured to restrict outside access to open ports at the network layer.

• Issue new SSL with certbot --nginx -d yourdomain.com -d www.yourdomain.com right after DNS switches
• Recreate cron jobs via crontab -e using your old cPanel list
• Plan domain email separately—MX records don't auto-migrate with your A record
• Re-test forms/login/checkout on your live domain after DNS fully propagates

When to Use This (Real-World Use Cases)

Migrating from shared cPanel hosting to a Droplet makes sense when your website clearly hits the limits of shared hosting—for example, when you're repeatedly hitting CPU/inode limits or getting warnings that you're exceeding your plan's resource quota. Moving to a Droplet with dedicated resources often solves this better than continually upgrading your shared plan. Another common case is when your development team needs a specific stack or extension that shared hosting doesn't support: a newer PHP version than your provider offers, continuous background workers or queue processors, Redis or Elasticsearch services, or applications written in languages other than PHP (Node.js, Python) that typical shared hosts don't easily accommodate. Droplet's root access gives you exactly what you need. Financially, teams running multiple websites who want to consolidate on one server for centralized management, or teams wanting predictable costs based on their chosen specs rather than tiered shared plans, often find Droplets offer better cost-per-resource value. Conversely, for very small websites—a company site with low traffic, no dev team to maintain infrastructure, no special technical needs—shared hosting with cPanel remains sensible. You exchange technical control for the provider handling security patches and uptime, which is worthwhile peace-of-mind if nobody on your team plans to run the server. Moving to a Droplet without a plan for ongoing maintenance creates security risk (unpatched software) that outweighs the benefits.

• Sites hitting CPU/inode limits on shared plans regularly
• Need newer PHP versions, background workers/queues, or services like Redis that shared hosting doesn't support
• Web apps written in non-PHP languages like Node.js or Python
• Want to run multiple websites on one server or control costs by spec selection
• Small sites, low traffic, no ops team—shared hosting with cPanel remains sensible

Common Mistakes and How to Avoid Them

The most frequent mistake is overlooking domain email entirely. Many teams focus on moving the website and forget that MX records point to the old mail server. When you cancel old hosting, your domain's email stops working immediately. Prevent this by reviewing MX records separately from A records and deciding on your email plan before shutting down old service. Another common pitfall is switching DNS before thoroughly testing your site on the new Droplet. Testing via /etc/hosts beforehand would catch broken pages or errors before real users see them, yet many skip this step and discover problems live. Version mismatches between old and new servers trip up many migrations—especially WordPress with many plugins, or legacy apps that rely on specific PHP extensions. Prevent this by documenting your old server's PHP version and extensions before migration, then matching them on your new Droplet before testing. Forgetting to recreate cron jobs is another silent failure: the site looks fine at first, then daily backups stop running, automated emails stop, or temp files fill your disk. Keep a list of all cron jobs from your old cPanel and recreate each one with crontab -e before shutting down old hosting. Finally, not backing up before migration is risky. Even with perfect planning, file transfers can corrupt data or imports can fail. Always create a full backup of your old server's files and database separately before starting, so you have something to restore from if anything goes wrong.

• Forgetting to plan domain email—MX records stay with old server after A record switches, breaking email
• Switching DNS before testing via /etc/hosts, so users see broken pages
• PHP version/extension mismatch between old and new server, causing plugins/features to break

Best Practices for a Smooth Migration

First, create a staging Droplet (separate from your production Droplet) to rehearse the installation, file migration, and database import process before touching your live server. This lets you find version or extension problems early, not when real users are affected. Second, apply security from day one: use SSH keys instead of password login, disable remote root login and create a non-root sudo user, enable ufw alongside DigitalOcean's free Cloud Firewall as two layers of protection, and close all unnecessary ports. This is stricter than what many shared hosts allow by default. Third, set up backups immediately: DigitalOcean's Droplet Snapshots cost $0.06/GiB per month for full-system backups, and Volumes cost $0.10/GiB per month for separate storage that scales. Combine scheduled database backups via cron with Droplet snapshots so you can recover both system-wide and database-specific failures. Fourth, monitor your Droplet's resources consistently using DigitalOcean's free Monitoring. Track whether your initial size choice fits your real traffic, and resize (vertical scaling) if RAM or CPU gets tight—you can upgrade without re-migrating all data. Finally, document your entire setup in a runbook for your team: every installation command, config file location, cron job, and firewall rule. This lets your team troubleshoot or rebuild the environment faster in the future without relying solely on the person who did the first migration.

• Create a staging Droplet to rehearse installation/migration/import before touching production
• SSH key + non-root sudo user + both ufw and free Cloud Firewall as two protection layers
• Set up backups from day one: Droplet Snapshots $0.06/GiB + Volumes $0.10/GiB per month (July 2026)
• Monitor DigitalOcean's free Monitoring regularly; consider vertical resize if resources approach limits
• Document your entire setup (commands, config locations, cron, firewall rules) in a runbook for your team

Get $200 Free Credit →