Thirteen sites, each on its own
The Asia Pacific region of a global hotel group: nine restaurant and bar websites and four hotel websites on WordPress, each run by its own property.
/work/hotel-sitesCame in under strain
- System
- 9 restaurant and bar sites, 4 hotel sites
- Symptom
- Shared servers, one IP. Hosting shut down by October 2022.
- Stack
- WordPress
- Region
- Asia Pacific
The piece Thirteen teeth, none touching, hung in waves of four, four and five.
- 13siteson their own machines
- 4 · 4 · 5three waves
- 7stepsper site
- Month 1rollback proven
- 7partiesone owner per task
The ask
Move the sites off hosting that was being shut down by October 2022, then host, maintain and support them, with each hotel dealing with us directly.
The real problem
The handover notes showed the sites grouped by location on shared servers, with one directory, one pool of CPU, IO and network, and one IP address between them.
A breach of one site could reach the others. A traffic spike on one slowed them all. One blacklisted IP could drop every site in search and push all their email into spam. A like-for-like move would have carried every one of those risks across, and the team that ran the sites was leaving.
Shared, then separate
- Idle
- Live
- Strain
- Fail
BeforeSites grouped on shared servers with one IP. A breach or a spike on one reached the rest.
AfterEach site on its own machines and its own IP, behind a load balancer and a CDN. A spike stays with the site where it starts.
What we built
Isolated hosting for every site. Each one has its own virtual machines and its own IP in a private cloud, behind a load balancer and a CDN, with backups, snapshots and object storage. Each has its own repository and its own path through review, pre-production and production; we added review apps, security checks and pre-production stages to the pipelines the sites already used. Capacity can scale up for new features and out for campaign traffic.
A monitoring dashboard shows every site's status, response time and the previous night's backup. Weave's new enquiry form went in during the move, replacing one that sent each enquiry to a staff inbox and kept no record of it.
How we made it hold
Rollback came first. In month one we set up the repository, pipelines and infrastructure, froze the code, backed up every site and proved rollback and disaster recovery, all before a single site moved.
The sites then moved in three waves of four, four and five. Every site went through the same seven steps: freeze and snapshot, migrate, deploy, test, hotel sign-off, tracking and hygiene, and the DNS swing. The old hosting stayed one change away until each swing held, and each wave had its own hypercare period while maintenance covered the sites already moved.
The limits were written into the plan from the start. Penetration testing and fixes to security issues already in the code were outside it, and the timeline said so. A responsibility matrix gave every task an owner across seven parties, including the outgoing team, who froze the code and took the snapshots before each move.
Backstage The decisions behind the build, and the hardest problem
Stack, as stated
WordPress. Isolated virtual machines and an IP per site in a private cloud, a load balancer and a CDN, backups, snapshots and object storage. Review apps, security checks and pre-production stages added to the pipelines the sites already used.
Decisions
Rollback before anything moved.
In month one the repository, pipelines and infrastructure were set up, the code frozen, every site backed up, and rollback and disaster recovery proven.
The same seven steps for every site.
Freeze and snapshot, migrate, deploy, test, hotel sign-off, tracking and hygiene, DNS swing. The old hosting stayed one change away until each swing held.
The limits written into the plan.
Penetration testing and fixes to security issues already in the code were outside it, and the timeline said so.
Ruled out
A like-for-like move.
It would have carried every shared-server risk across.
The hardest problem
The team that ran the sites was leaving. A responsibility matrix gave every task an owner across seven parties, the outgoing team among them, and they froze the code and took the snapshots before each move.
The difference
- The group awarded the migration after the response and walkthrough, and it was delivered.
- All thirteen sites run on their own machines in a private cloud. A breach, attack or spike stays with the site where it starts.
- Every wave followed the same migrate, deploy and rollback steps.
- A better enquiry form went live with the move.
- The shared servers were shut down and archived after every site was checked on the new setup.
- Every task had a named owner across seven parties.
