Linux Sysadmin/WordPress Migration

1. Provision & baseline the new server
Hardware / provider

UK-based dedicated server

AMD EPYC 4344P or better

64GB RAM

NVMe storage

≥1Gbps guaranteed bandwidth

OS & access

Install supported modern Linux (Ubuntu LTS / AlmaLinux / Rocky)

Fully update OS, kernel, packages

Set timezone to UTC

SSH key-only access

Disable password logins

Confirm remote console / recovery access

2. Install & configure control panel
Plesk

Install Plesk Obsidian – Web Pro licence

Enable only required services:

Web

Mail

Backups

Disable unused extras

3. Secure the base system

Firewall:

Open only required ports (80/443, mail ports, SSH restricted)

Fail2ban enabled (SSH + mail)

No public database exposure

System users and permissions locked down

4. Build a clean, modern web stack
Web server

Nginx (primary)

PHP via PHP-FPM

PHP (explicit configuration – not defaults)

PHP 8.3 (unless incompatibility found)

OPcache enabled and tuned

Set production-grade limits:

Memory

Upload size

Execution time

Input vars

Database

MariaDB

Tune for:

~1GB WordPress database

Proper InnoDB buffer pool sizing

Sensible max connections

Enable slow query logging temporarily for tuning

Caching

Install and enable Redis

Decide on one caching strategy:

Server-side page cache (FastCGI)

Redis object cache

Remove overlapping / redundant WordPress cache plugins

Ensure correct behaviour for:

Logged-in users

WooCommerce cart & checkout

Admin area

5. Email migration & reliability (critical)
Mail hosting

Enable Plesk mail stack (Postfix + Dovecot)

One email domain

~200 mailboxes

Migration

Export and import all mailboxes

Passwords must remain unchanged

Preserve folders and timestamps

Validate mail flow before cutover

Configuration

Fix SMTP conflicts in WordPress

Choose one SMTP solution

Validate:

Password reset emails

WooCommerce order emails

Form submissions

Bulk mail (if still used)

Configure SPF, DKIM, DMARC, PTR

6. WordPress migration

Take a clean backup of WordPress (files + DB)

Restore onto new server

Configure:

wp-config.php memory constants

Correct file permissions

Validate:

Front-end

Admin

Elementor

WooCommerce checkout

Forms

No leftover legacy config

7. Cron & background jobs

Disable traffic-based WP-Cron

Configure real system cron

Confirm:

WooCommerce tasks

Email jobs

Scheduled maintenance

8. Backups & recovery (non-negotiable)

Configure daily automated backups

Store backups off-server

Agree retention policy

Test a restore (site + database + mailbox) before DNS cutover

Document restore process

9. Monitoring & logging

Enable:

CPU / RAM monitoring

Disk usage alerts

Review:

Nginx error logs

PHP error logs

Database logs

Confirm no silent failures post-migration

10. Staging, cutover & downtime control
Before cutover

Full staging clone on new server

Validate everything works end-to-end

Lower DNS TTLs

Cutover

Weekend window preferred

Minimal downtime

Final data sync

Switch DNS

Monitor live traffic and mail

Rollback

Clear rollback plan if something fails

11. Documentation & handover

Developer must provide:

Plesk login details

PHP / DB / cache configuration summary

Mail server details

Backup & restore instructions

What not to change

Any known limitations

12. Success criteria (how the job is judged)

After completion:

Faster TTFB and admin performance

Stable WooCommerce checkout

Reliable email delivery

No legacy OS or kernel risk

No stacked caching

Tested backups

Platform ready to scale without re-architecture

One-line summary you can give any developer

“This is a clean rebuild on a new EPYC dedicated server with Plesk Web Pro, followed by a controlled WordPress + mail migration, performance tuning, tested backups, and a low-downtime cutover.”

Current situation (now)

Website and email run on a shared VPS with a legacy Linux stack, Cpanel

Old kernel and mixed configurations increase risk and complexity

WordPress performance is constrained (disk I/O, DB, concurrency)

Caching and email setups are overlapping and inconsistent

Backups and recovery have not been fully tested

Platform is functional but not future-proof

Target situation (where we’re going)

Move to a UK-based dedicated server (AMD EPYC, NVMe, 64GB RAM)

Rebuild on a modern, fully supported Linux OS

Use Plesk Web Pro for clean management of web, email, and backups

Deploy a simplified, deliberate performance stack

Migrate WordPress and email with minimal downtime

Implement tested backups, monitoring, and documentation

End state: faster, safer, scalable, and easier to manage

Everything is working as now, to set specifications.