What does this service cover?
Environment inventory
The first step is documenting PHP versions and modules, database versions, disk usage, inode pressure, web-server type, caching layers, cron jobs, SSL certificates, DNS records and mail dependencies. This becomes the migration checklist for the destination. WordPress VPS and server migration for cPanel, Plesk, cloud servers and custom Linux stacks, including PHP, database, SSL, DNS and post-move validation.
Server-to-server transfer
Files are transferred with methods appropriate to the access available, databases are exported consistently, and ownership and permissions are corrected on the destination. Large sites may use rsync-style incremental copies so the final transfer window stays small.
Control panels and custom stacks
I handle common moves involving cPanel, Plesk, CyberPanel and unmanaged Linux servers. When the destination is a custom stack, the web server, PHP-FPM, database service, Redis or object cache and TLS configuration are validated as part of the move.
Cutover and rollback
DNS is changed only after the destination is tested. The old server is kept intact during the validation period whenever possible, providing a practical rollback path if an unexpected application-specific issue appears.
What is the typical scope?
Every engagement starts from the same place: a clear, agreed list of what is included before any work begins.
- Runtime versions and required extensions
- Services, firewalls and scheduled jobs
- Backups, monitoring and operational ownership
The exact scope is confirmed from the real site and problem before changes are made.
How does the work proceed?
- Inventory the environment: document PHP versions and modules, database versions, web-server type, cron jobs, SSL, DNS and mail dependencies as the migration checklist.
- Prepare the destination: configure the new server's stack — web server, PHP-FPM, database, TLS, firewall — to match what the application needs.
- Transfer incrementally: move files and databases with methods suited to the access available; large sites sync incrementally to keep the final window small.
- Cut over with rollback ready: switch DNS only after the destination is tested, keeping the old server intact during validation.
What you need to provide
Most of the technical work is on my side. To start, I usually need:
- Root or sudo SSH access to both servers (or control-panel credentials)
- A list of everything hosted on the source — sites, mail, cron jobs, other apps
- DNS management access
- Preferred cutover timing and who can approve it
Typical timelines
Like-for-like panel moves take 3–7 days. Custom-stack builds add configuration time — typically 1–2 weeks total including testing. The DNS cutover itself is a short, scheduled event.
Frequently asked questions
How is a server migration different from a WordPress migration?
A WordPress migration moves the application; a server migration also moves the infrastructure — PHP builds, database versions, web-server rules, firewalls, cron, TLS. Both layers have to match.
Can you migrate from cPanel to a plain Linux VPS?
Yes. The destination stack — web server, PHP-FPM, database, cache, TLS — is configured and validated as part of the move, not assumed.
Will my PHP version change?
Only deliberately. I document the current runtime first and match or upgrade it intentionally, testing the application against the change.
What about email hosted on the old server?
Server mail is inventoried separately — it does not automatically follow the website. MX routing and mailbox moves are planned explicitly.
Do you offer ongoing server management?
Migration and handover are the core scope. Ongoing administration and incident response can be agreed explicitly if you need them afterwards.
What if the old server hosts other things besides WordPress?
Those dependencies are inventoried before the destination is prepared — custom apps, cron-driven scripts and all. Surprises after cutover are what the inventory prevents.
What we confirm together
A server can host workloads beyond WordPress. Those dependencies need an inventory before the destination is prepared. Ongoing server administration and incident response should be agreed explicitly if required after migration.
Before starting, we agree on access, affected systems, testing, timing and the handover. Hosting subscriptions, premium software and work outside that scope are identified separately.
Start with a clear scope
Describe your website and what needs to happen. You will receive a fixed scope, price and timeline before any work starts — no passwords needed at the enquiry stage.