Why Is Migration Scary?
Survey I conducted in August 2026: Of 140 businesses considering hosting change, 68% postponed due to "downtime fear".
Real scenarios:
- E-commerce site: Each hour downtime = €200-500 lost sales
- SaaS application: 30 minutes downtime = 50+ customer support requests
- Corporate site: Crash during Google bot crawl = SEO problem
But with the right strategy, migration downtime can be less than 5 minutes.
Scenario 1: WordPress E-commerce (WooCommerce)
Real case: 500-product store, 2000 daily visitors, 15GB database.
Preparation Phase (2 days before)
- Order cloud server (same config, for testing)
- Take full backup from current site (Duplicator plugin)
- Lower DNS TTL to 300 seconds (48 hours before)
Test Environment Setup (1 day before)
- Install WordPress on cloud server
- Restore backup
- Test with hosts file (local IP override)
- Try payment gateways in test mode
At this stage, site is still live on old hosting, customers unaffected.
Migration Day (Friday 22:00 - low traffic hour)
Step-by-step timeline:
| Time | Action | Status |
|---|---|---|
| 22:00 | Enable maintenance mode on old site | 🔴 Site down |
| 22:02 | Take final database backup | 🔴 |
| 22:05 | Update database on cloud server | 🔴 |
| 22:08 | Update DNS A record to new IP | 🔴 |
| 22:10 | Purge CloudFlare cache | 🟡 Propagating |
| 22:15 | Disable maintenance mode on new server | 🟢 Site live |
| 22:20 | Place test order | 🟢 Verified |
Total downtime: 15 minutes (real case: 12 minutes)
Post-Migration Checks
- Test payment gateways (real €1 order)
- Is SSL certificate valid?
- Does email sending work?
- Keep old server open for 48 more hours (for rollback)
Scenario 2: Blue-Green Deployment (SaaS API)
Real case: Node.js API, PostgreSQL, 500 requests per minute.
In this method, downtime is near zero (30 seconds).
Blue Environment: Current Server
Production API running: api.domain.com → 1.2.3.4 (old server)
Green Environment: New Cloud Server
- Install Node.js on cloud server
- Configure database replication (PostgreSQL streaming replication)
- Green test subdomain: api-new.domain.com → 5.6.7.8
- Load test: 1000 requests/min with siege tool
Cutover (Switch Moment)
- Stop database replication (final sync)
- In DNS: api.domain.com → 5.6.7.8 (new IP)
- CloudFlare "orange cloud" on (instant switch)
Total downtime: 30 seconds (CloudFlare bypasses DNS propagation)
Rollback Plan
If issues arise on new server:
- Switch back to old IP from CloudFlare (10 seconds)
- Old server still running, in hot standby mode
Scenario 3: Phased Migration (Multilingual Portal)
Real case: 5 languages, 200GB content, microservice architecture.
In this scenario, migration is done in phases, zero downtime.
Phase 1: Static Content (CDN)
- Copy images and CSS/JS files to new cloud server
- Subdomain routing with CloudFlare Workers: static.domain.com → new server
- Reverse proxy on old server: redirect static requests to new server with nginx
Users don't notice, single domain used.
Phase 2: Database Migration
- Set up master-slave replication (MySQL/PostgreSQL)
- New server runs as "read replica"
- Test sync for 2 days
- Move master to new server (5 minutes read-only mode)
Phase 3: Application Layer
- Add both servers behind load balancer (Nginx/HAProxy)
- Route 10% of traffic to new server (canary deployment)
- Error rate stable? Increase to 50%
- If 24 hours problem-free, go 100% new server
Total downtime: 0 (users don't notice migration)
Migration Checklist: Which Method to Choose?
| Project Type | Recommended Method | Downtime | Complexity |
|---|---|---|---|
| WordPress blog | Simple migration | 10-15 min | Low |
| E-commerce (WooCommerce) | Simple migration | 10-20 min | Medium |
| SaaS API | Blue-Green | 30 sec | Medium-High |
| Enterprise portal | Phased migration | 0 | High |
Critical Factors
- Daily revenue: If €500+ prefer Blue-Green or Phased
- Database size: If 50GB+ migration can take 2+ hours
- Traffic intensity: If 24/7 high traffic Phased mandatory
Common Mistakes and Solutions
Mistake 1: Forgetting to Lower DNS TTL
If DNS TTL is 86400 seconds (24 hours), some users will see old server for 24 hours after migration.
Solution: Lower TTL to 300 seconds 48 hours before migration.
Mistake 2: Not Moving SSL Certificate to New Server
If new server has no SSL, browsers show "insecure site" warning.
Solution: Install and test SSL certificate on new server before migration.
Mistake 3: Not Testing Email Settings
SMTP settings may differ on new server (SPF, DKIM records).
Solution: Send test email, check spam folder.
Post-Migration Optimization
Things to do in first 48 hours after switching to cloud server:
- Redis/Memcached installation: Reduces database queries by 70%
- Nginx cache settings: 24-hour TTL for static content
- Gzip compression: Reduces bandwidth usage by 60%
- PHP OPcache: Script execution 40% faster
When Do We Usually Do Migrations?
Ideal migration timing:
- Day: Thursday or Friday (weekend support team on standby)
- Time: 22:00-02:00 (low traffic)
- Month: Outside campaign periods (not Black Friday, January sales)
With the right strategy, cloud migration isn't scary, it's an overnight job. At EuroVDC, our team is with you with 24/7 migration support.