You've just signed up for the Ember plan and your client's portfolio site lives on a shared host in the US. The deadline is next Thursday, and you need a clear picture of what we will ask for, what we will do, and how long each stage should take.
Below is the exact flow we follow for every migration, whether the site is a single-page landing page or a 50-GB WordPress installation with a large media library. The process mirrors the steps described in our "How to Migrate Your WordPress Site to TrueCore Hosting" post, but it adds the behind-the-scenes actions we perform on the server side.
What We Need From You Before Day-One
- Domain ownership proof - a screenshot of the registrar dashboard or a login email that shows you control the domain.
- Current site credentials - FTP/SFTP username and password, or SSH key if you already use SSH. For WordPress sites, an admin account with the capability to export content.
- Database access details - host, port, username, password, and the name of the database if the current host uses MySQL or PostgreSQL.
- Backup preferences - let us know if you want a pre-migration snapshot stored in your Backblaze B2 bucket.
We collect these items through a secure form in the customer portal. The form automatically encrypts the data at rest, matching the encryption we use for restic backups.
Stage 1 - Initial Assessment and Planning
Our engineers log into the source server and run a quick inventory:
du -sh /var/www/html # total size of the webroot
find /var/www/html -type f | wc -l # file countThe output tells us whether the site fits within the storage limit of the chosen plan. For example, a site that reports 12 GB of data will need the Blaze plan (60 GB) instead of Ember (40 GB). If the site uses a database larger than the plan's allowance, we discuss options with you before proceeding.
The assessment also reveals any custom server configuration that may need recreation on our side, such as specific .htaccess rules or custom PHP extensions. We note those for the next stage.
Stage 2 - Secure Backups
We always start with a full backup, even if you have recent snapshots on the old host. The backup runs with restic and is encrypted before leaving the source server:
restic -r b2:mybucket:/site-backup \
--password-file /root/backup.pass \
backup /var/www/htmlFor database-driven sites we dump the DB in a format the target can import:
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > db.sql
# or
pg_dump -U $PG_USER -Fc $PG_DB > db.dumpThe backup typically completes in 30 minutes for a 10 GB site and up to 2 hours for a 50 GB site with many small files. The process runs in the background while we continue with the next steps.
Stage 3 - Setting Up the Destination Environment
Once the backup is stored safely, we allocate resources on the appropriate node:
- Flameling for a single-site static site (≤4 GB).
- Ember for up to three sites or a modest WordPress install (≤40 GB).
- Blaze or Inferno for larger collections.
The allocation includes:
- a freshly provisioned user account (
user123) with its own flame-bubble container, - an nginx 1.28 pod-nginx process,
- PHP-FPM 8.3,
- for Ember-plus plans, a dedicated PostgreSQL 16 instance,
All containers inherit the fleet-wide kernel resource limits enforced by the flame-bubble container system (cgroups).
We then import the website files:
rsync -avz --progress \
/mnt/backup/site/ user123@ember.truecorehosting.com:/home/user123/www/For MySQL-based sites we restore into a local PostgreSQL 16 instance using the pgloader tool, which converts the schema automatically. For SQLite-only sites (Flameling plan) we simply place the db.sqlite file in the designated path.
The file transfer time mirrors the backup size: roughly 1 GB per minute over our private WireGuard link, subject to the source's upstream bandwidth.
Stage 4 - DNS Preparation and Testing
Before any DNS change we verify the site works from the new host. You can test locally by adding an entry to your hosts file:
159.195.31.27 yourdomain.comThe address above is only an example — use your node's actual IP, shown in the portal, in place of it. We run a quick health check with curl -I https://yourdomain.com and confirm that the SSL certificate is present (TrueCore issues it automatically once the name resolves).
If the site uses external services—email via Purelymail, third-party APIs, or a custom cron job—we run a checklist to confirm connectivity. Any missing DNS records are added to flame-dnsd while we still have the old nameservers in place, so they will be live the moment you switch.
Stage 5 - Nameserver Switch and SSL Activation
When the test passes we ask you to update the registrar's nameservers to:
ember.truecorehosting.comspark.truecorehosting.comlitespeed.truecorehosting.com
Propagation on our authoritative DNS typically finishes in under 2 hours; the in-memory caches on our three-node fleet refresh within five seconds thanks to the inotify-driven sync.
As soon as the nameserver change hits and traffic starts landing on the new node, flame-sentinel sends a heartbeat to our Discord channel confirming the site is live.
SSL provisioning is automatic. The certificate is issued by Let's Encrypt and renewed every 90 days without manual steps. Most users see the lock icon appear within 5 minutes of the DNS switch.
Stage 6 - Post-Migration Validation
After DNS propagation we run a final suite of checks:
- HTTP status for every known URL (200 OK expected).
- Form submissions for contact forms or checkout flows.
- Email delivery via Purelymail (test to a Gmail address).
If any check fails we roll back the DNS entry to the old host, fix the issue on the new node, and repeat the switch. The rollback is instant because the old host remains online until you confirm everything works.
What Can Go Wrong and How We Handle It
| Issue | Likely cause | Resolution | |-------|--------------|------------| | Missing media files | Source host blocked large file downloads | We pull the wp-content/uploads directory via SFTP and rsync it manually | | Database connection error | PostgreSQL 16 config not matching old MySQL credentials | Use pgloader to translate the dump, then edit wp-config.php with the new DB credentials | | DNS TTL caching | Registrar set a high TTL (24 h) | Advise lowering TTL to 300 seconds 24 hours before migration; otherwise expect longer propagation | | SSL not issuing | Domain still points to old nameservers | Verify DNS change fully propagated before waiting for Let's Encrypt |
We never promise zero downtime, but most migrations finish with under 5 minutes of real-world impact for sites under 10 GB. Larger sites—say a 45 GB ecommerce store with 200 k images—may see up to 30 minutes while the final sync runs and the DNS propagates.
How Long the Whole Process Takes
| Site size | Typical total time | |-----------|-------------------| | Small static site (≤1 GB) | 1 hour total | | Medium WordPress site (1-10 GB) | 2-3 hours total | | Large media-rich site (10-50 GB) | 4-8 hours total |
These estimates include the initial assessment, backup, file transfer, DNS switch, and post-migration validation. The clock stops when you give the final "go-live" sign-off.
Keeping You Informed
We send an email at each major milestone: assessment complete, backup finished, files staged, DNS changed, and final verification. The same format was used for the maintenance windows described in our "What Actually Happens During a Server Maintenance Window" article, so you'll recognize the timestamps and contact details.
If you hit an unexpected snag, our support portal offers a ticket with real-time status updates. We respond within business hours and provide out-of-hours alerts for critical failures.
Migrating a site is a finite, repeatable process. By giving us the required credentials, letting us create a full backup, and following the DNS update steps, you can expect a smooth transition with minimal disruption. If you have a launch window or a marketing campaign, let us know early and we'll schedule the migration to fit your calendar.