¿Worried about losing SSL or backups during a host move? The risk of broken HTTPS, lost backups or long downtime is real for migrations that lack a repeatable playbook. For a reliable Servicio de migración segura entre hosts preservando SSL y backups the process must combine verification, exact certificate handling, atomic cutover and tested rollback criteria.
A precise actionable plan reduces downtime, removes guesswork and preserves private keys and backup integrity. The steps below provide a technical playbook, commands, verification checks and rollback templates for migrations between shared hosts, VPS, and cloud providers.
Key takeaways: what to know in 1 minute
- Lower DNS TTL early to enable fast cutover; plan at least 48–72 hours before final migration.
- Preserve certificate files and private keys by securely copying certificate bundle, private key and chain to the new host before DNS change.
- Validate backups with checksums and test restores; do not trust a backup without a checksum or a test restore.
- Use rsync + downtime window strategy to sync large files and perform a final rsync for atomic cutover.
- Prepare a rollback plan with acceptance criteria and automated scripts to revert DNS and services within the target RTO.
Pre-migration checklist for servicio de migración segura entre hosts preservando SSL y backups
- Inventory domains, hostnames, IPs, ports and services (web, db, mail).
- Export SSL: certificate (.crt/.pem), private key (.key), intermediate bundle, and CSR if available.
- Verify backup policy: full backups, incremental, retention and locations.
- Confirm access: SSH keys, control panel credentials, API tokens for both source and destination.
- Set DNS TTL to low value (60–300s) at least 48 hours before planned cutover.
- certificate file (domain.crt or fullchain.pem)
- private key (domain.key)
- intermediate CA bundle (chain.pem or ca-bundle.crt)
- CSR (optional, domain.csr)
Commands to inspect certificate details before transfer:
- openssl x509 -in fullchain.pem -text -noout
- openssl rsa -in domain.key -check
Verify certificate fingerprint and validity period:
- openssl x509 -noout -fingerprint -sha256 -in fullchain.pem
Secure transfer of certificates and backups (commands and permissions)
Use secure channels and minimal exposure. Preserve file ownership and permissions to avoid private key leaks.
- Copy certificates with scp (example):
scp -P 2222 /etc/letsencrypt/live/example.com/privkey.pem user@newhost:/tmp/privkey.pem
scp -P 2222 /etc/letsencrypt/live/example.com/fullchain.pem user@newhost:/tmp/fullchain.pem
- Better: use rsync over SSH with restrictive umask and then set permissions:
rsync -avz -e "ssh -i /path/to/key" /etc/letsencrypt/live/example.com/ user@newhost:/tmp/example.com/
ssh user@newhost 'sudo chown root:root /tmp/example.com/* && sudo chmod 600 /tmp/example.com/privkey.pem && sudo chmod 644 /tmp/example.com/fullchain.pem'
- Move into the final certificate directory on destination with appropriate SELinux context if applicable (restorecon or setenforce checks).
Backup transfer commands and integrity checks
- Database export (MySQL/MariaDB):
mysqldump --single-transaction --quick --routines --triggers -u root -p database > /tmp/database.sql
gzip -c /tmp/database.sql > /tmp/database.sql.gz
sha256sum /tmp/database.sql.gz > /tmp/database.sql.gz.sha256
rsync -az --delete --numeric-ids --progress /var/www/html/ user@newhost:/var/www/html/
- Verify checksums after transfer:
ssh user@newhost 'sha256sum /var/www/html.tar.gz' && scp user@newhost:/tmp/database.sql.gz.sha256 /tmp/
- For large datasets prefer incremental rsync and an LVM snapshot or filesystem snapshot to ensure consistency.
Table: quick comparison of common migration methods
| migration method |
downtime |
complexity |
preserves ssl/private key |
best for |
notes |
| rsync + DNS cutover |
low (minutes) |
medium |
yes if keys copied |
static sites, php apps |
final rsync + DB lock-free dump needed |
| database replication + switch |
near-zero |
high |
yes |
high-traffic apps |
requires setup time and db creds |
| full image snapshot (VM) |
low |
medium |
yes |
VPS/cloud to cloud |
cloud-specific drivers and networking tweaks |
| control panel migration (cPanel/Plesk) |
variable |
low-medium |
sometimes (depends on provider) |
managed shared hosting |
confirm key export |
Step-by-step playbook: secure transfer preserving SSL and backups
- Audit and inventory everything: cert paths, backup locations, DNS provider, and IPs.
- Lower TTL on authoritative DNS records to 60–300s at least 48 hours before cutover.
- Create verified backups: files, databases, mailboxes (IMAP) and export checksums.
- Transfer backups and certificate material to the new host using rsync/scp over SSH.
- Install certificate files into web server config on destination (Nginx/Apache) and test locally via /etc/hosts.
- Perform a staged test using host overrides or internal network to verify HTTPS, site functionality and cron jobs.
- Schedule maintenance window or plan atomic cutover: final DB dump, last rsync, swap DNS.
- Monitor logs, run smoke tests and keep rollback plan ready.
Nginx example server block (certificate installation)
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/ssl/certs/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/private/example.com/privkey.pem;
ssl_trusted_certificate /etc/ssl/certs/example.com/chain.pem;
root /var/www/html;
index index.php index.html;
}
After placing files, test:
sudo nginx -t && sudo systemctl reload nginx
Then verify remotely:
openssl s_client -connect example.com:443 -servername example.com < /dev/null
Handling Let's Encrypt and rate limits without service loss
- If the source host manages Let’s Encrypt, export fullchain and privkey before stopping services.
- For reissuing on destination, prefer to re-use the same private key and request a certificate with Certbot using the DNS challenge if webroot validation is unstable.
- Check rate limits: Let’s Encrypt rate limits.
- Use DNS challenge with provider API (Certbot DNS plugins) to avoid HTTP validation loops.
Cutover strategies for minimal downtime
- TTL strategy: set low TTL early, schedule at low-traffic time.
- Final sync: freeze writes or use application-level quiesce, then run final incremental rsync and last DB dump.
- DNS swap: update A/AAAA records to new IP and monitor propagation.
- Proxy approach: set up new host behind a proxy or use the old host as reverse proxy to new host while DNS caches propagate.
Example final cutover commands
mysqldump --single-transaction --quick -u root -p database > /tmp/final.sql
gzip /tmp/final.sql
scp /tmp/final.sql.gz user@newhost:/tmp/
rsync -az --delete --bwlimit=5000 /var/www/html/ user@newhost:/var/www/html/
- After verification, update DNS A record to newhost IP and monitor connectivity.
Mail and IMAP preservation during host migration
- Export entire maildir or IMAP store; for IMAP servers, use imapsync to preserve flags and message UIDs:
imapsync --host1 old.imap.server --user1 user --password1 'pass' --host2 new.imap.server --user2 user --password2 'pass'
- Test login and message integrity on a single account before bulk migration.
- If using hosted email (Gmail/Office365), migration may be limited to routing and MX changes instead of mailbox transfer.
Handling different control panels and file paths
- cPanel paths: /home/username/
- Plesk paths: /var/www/vhosts/domain/
- DirectAdmin: /home/user/domains/
Map paths before transfer and adjust user permissions and PHP-FPM pools on destination. If migrating from cPanel to cPanel, consider the built-in transfer tool but still export SSL keys separately for safety.
Verification and post-migration checklist
- DNS: correct A/AAAA records, TTL restored to default after 24–48 hours.
- HTTPS: certificate chain correct, no mixed content, HSTS headers if used.
- Application: database connectivity, background jobs, session storage, and caches.
- Backups: new host backup jobs active and tested.
- Logs: error.log and access.log monitored for anomalies.
Commands for quick checks:
- curl -Ik https://example.com | head -n 20
- openssl s_client -connect example.com:443 -servername example.com
- dig +short example.com @8.8.8.8
Practical example: how it actually works
📊 Case data:
- Source: shared host (PHP site, 10 GB web files, 4 GB DB)
- Destination: VPS with public IP, full root access
🧮 Process:
- Lower TTL to 120s (48h prior)
- Export DB with mysqldump and gzip, checksum created
- Rsync files in background (first pass)
- Copy SSL files to /tmp, install and test with /etc/hosts override
- Final db dump and final rsync within scheduled 15-minute window
✅ Result: Cutover completed in 6 minutes, HTTPS preserved, no data loss, rollback script available
Visual flow: migration workflow (textual)
Step 1 🔍 inventory → Step 2 🔁 backup & transfer → Step 3 🔐 copy SSL → Step 4 ⚡ final sync & DNS → ✅ Success
Checklist visual: secure transfer steps
Before migration
- ✓Inventory & TTL
- ✓Backups & checksums
- ⚠Export SSL keys
Cutover
- ✓Final rsync
- ✓Swap DNS
- ✗Monitor and rollback if needed
Advantages, risks and common mistakes
✅ Benefits / when to apply
- Significant reduction in unexpected HTTPS breakage when keys are preserved and installed before DNS change.
- Shorter downtime when using incremental sync and final atomic cutover.
- Easier rollback when DNS TTLs are lowered and rollback script prepared.
⚠ Errors to avoid / risks
- Copying private keys over unsecured channels or leaving them with wrong permissions.
- Failing to test certificate chain and OCSP stapling on new host.
- Ignoring mail migration details and losing IMAP flags.
- Overlooking provider-specific rate limits for certificate reissue (Let’s Encrypt).
Migration pros & cons (visual)
Migration pros and cons at a glance
Pros
- ✅ Preserve SSL and private keys
- ✅ Minimized downtime with rsync
- ✅ Verified backups with checksums
Cons
- ⚠ Requires SSH/root access
- ⚠ Potential complexity for large DBs
- ⚠ Need DNS TTL planning
Questions frequently asked
How to preserve private keys when moving hosts?
Copy private keys over SSH or rsync with strict permissions, then set owner to root and chmod 600. Avoid email or unsecured storage for private keys.
Can Let’s Encrypt certificates be migrated between hosts?
Yes. Copy fullchain.pem and privkey.pem. If automatic renewal is required, configure Certbot or a DNS-based renewal on the destination; check rate limits at Let’s Encrypt limits.
How to ensure backups are valid after transfer?
Use checksums (sha256sum) and perform at least one test restore on a staging environment to confirm data integrity.
Is zero downtime possible with large databases?
Near-zero downtime is possible with replication (MySQL replication, logical replication) or phased traffic routing. For most small-to-medium sites, a short maintenance window plus final incremental sync achieves minimal downtime.
How to migrate IMAP mailboxes without losing flags?
Use imapsync to preserve flags and timestamps. Test on a single account first and validate folder structure before bulk sync.
What if the control panel does not export SSL keys?
Access the filesystem directly or request the key export from the provider. If impossible, reissue certificates using DNS validation to avoid exposing private keys.
When to rollback after a failed cutover?
If core application errors persist beyond the agreed acceptance window (RTO), revert DNS to the previous IP and restore any critical data from the verified backup; perform root cause analysis before retry.
Your next step:
- Inventory everything now: domain list, cert paths, backup locations and DNS provider.
- Create and verify full backups with checksums; transfer certificates to a secure staging host and test installs.
- Prepare and automate rollback scripts, lower TTLs and schedule a short maintenance window for final cutover.
