Zero-downtime upgrade
Your visitors see the existing site the whole time. The new stack is verified in parallel on the same server and only then does traffic move — there is no moment when the service is down.
Process
Zero-downtime upgrade is how the work runs
This is the order we actually follow on client work. Because the cutover runs in parallel, the live site never stops for a moment, and the switch happens only after verification is completely finished.
- 0 minutes of downtime
- 9 standard steps
- Measured before and after, same conditions
01 — Principles
Three principles
Your existing service comes to no harm
We secure a full backup before starting, and every change is verified on a copy kept separate from your live site. Until the cutover not a single file on the running original changes, and at any stage we can return instantly to the pre-work state — your existing service is never harmed or disadvantaged.
What did not improve goes in the report too
Anything we could not fix is written down with the reason — a paid licence, a decision that is yours to make — along with what would resolve it. That is what lets you decide the next step yourself.
02 — Procedure
Nine steps
From assessment to cutover, each step has to finish before the next one starts. We create the point we can roll back to before we move.
-
01
Assessment
Within one business day we measure core, PHP and database versions, plugin vulnerabilities (WPScan plus a security checklist) and response times. Latent problems that never show on screen — a broken drop-in, syntax that is no longer supported — go on the list too.
-
02
Scope confirmed · payment
Based on the assessment we put the scope, the schedule and what is and is not included in writing. Work starts once payment by bank transfer or PayPal clears.
-
03
Server preparation — checking the Docker components
We check the server for the pieces we need — Docker, containerd, the docker compose plugin. Missing ones get installed, existing ones are left alone; your current server configuration is not touched. The Docker stack needs at least 10 GB of free disk space, and 20 GB or more is recommended; if that space cannot be secured we stop the work and refund you in full under the refund policy.
-
04
Full backup
Source, database and uploads are backed up in their pre-work state. Before anything else we secure a point we can restore from at any stage.
-
05
Source handover · PHP 8 compatibility fixes
We pull the source and a copy of the database into a local working environment and, in a complete test setup, fix the syntax that breaks on current PHP and every call site for a removed API, one at a time. The warnings and errors that were never visible on screen get cleared here.
-
06
Private Git repository
The corrected source goes into a private Git repository and version control begins. Every change after that leaves a history, so what changed and why can always be traced.
-
07
Docker Compose stack · parallel verification with no downtime
The tuned docker-compose stack comes up in parallel on the same server and the same domain. Ordinary visitors keep seeing the existing site; only the reviewers you nominate are routed to the new stack. The rehearsal runs on a copy of the production database, so live data stays untouched until the cutover.
-
08
Staged upgrades · optimization · hardening
We upgrade core, then theme, then plugins, then the database engine, and put in the three cache layers — Redis object cache, nginx page cache, OPcache — along with the security hardening. Flows with money in them, like payments, orders and forms, are regression-tested against real scenarios.
-
09
Re-measure · cut over · hand over
We measure again with the same tools under the same conditions, build the before/after report, and once verification is done move all visitors to the new stack. That cutover has no downtime either. You receive the docker-compose configuration and the Git repository, plus two weeks of free defect support.
03 — Your part
This is everything we need from you
The technical side is entirely ours. We do not ask for server credentials on the application form — once payment clears you submit them securely, at the point they are actually needed, from a progress page only you can log into.
-
01
Send your application
Just your site address and server environment. No credentials are asked for at this stage.
-
02
Payment
Pay by bank transfer or PayPal. Once it clears we email you a login for your progress page.
-
03
Track your progress
Log in with the password from that email and you can see which stage your job is at, whenever you want.
-
04
Submit the credentials
From inside that logged-in page, submit the server IP and the root (or sudo) account we need to begin. Please include your WordPress administrator username and password as well — they are needed for the upgrade and for verification afterwards. Until you submit, the job waits safely and nothing starts; what you send is encrypted and used for this job only.
-
05
Review the report
When the work is done you get the measured before/after report and can see for yourself, in numbers, what improved and by how much.
-
06
Take delivery
Take over a faster, safer site along with the docker-compose configuration and the Git repository, backed by two weeks of free defect support.