How we would move an online store from shared hosting to a managed server, with caching, tested backups and monitoring, without changing platform.
SOLUTION SCENARIO
This is a solution scenario: it describes how we would approach the case, not a delivered project. The company is a typical example. Timelines and phases are indicative, to be confirmed after the feasibility analysis.
AT A GLANCE
A growing online store on shared hosting that slows down on promotion days can move to a managed cloud server without changing platform. We would start by measuring the real load, then move the store to a dedicated environment with caching, verified backups and monitoring. The switch would happen in a low-traffic window, with a rollback plan ready.
THE TYPICAL COMPANY
Picture an online homeware store that started out on cheap shared hosting. The catalogue has grown, the campaigns work, and on promotion days the site becomes slow and sometimes responds with errors.
The backup is “included in the plan”, but nobody has ever tried to restore it.
Why shared hosting cannot keep up with a growing e-commerce store.
Resources are shared with other sites and cannot be guaranteed at peak times.
Cart and checkout cannot be cached like other pages, so they put load on the server.
An outage is discovered by customers, not by an alerting system.
It is not clear who steps in, or how quickly, if the store goes down.
Four phases. Durations are indicative, to be confirmed after the feasibility analysis.
Visits and orders on peak days, response times, the heaviest plugins, database size: so that sizing is based on data, not guesswork.
A copy of the store on a managed server, protected and not indexable. PHP and database upgrades, cache configuration and a load test that simulates a promotion.
A low-traffic window, DNS record TTLs lowered in advance, synchronisation of the latest orders. The old hosting stays active for a few days as a rollback plan.
Checks on errors, response times and transactional emails. Then a document covering architecture, access, backups and the procedure in case of failure.
STACK
| Component | Choice |
|---|---|
| Server | Dedicated virtual machine or container in an EU data centre |
| Web server and cache | Page and object caching, with cart and checkout excluded |
| Network | CDN and web application firewall in front of the server |
| Backup | 3-2-1 rule: a full daily copy, frequent database copies, one off-site copy and periodic restore tests |
| Monitoring | Uptime, disk space, certificates and backup results, with alerts |
| Dedicated sending service for order emails, with SPF, DKIM and DMARC |
An e-commerce store handles customer data and payments, even if card details go through the payment provider. Scheduled updates, two-factor authentication for admin access and a log of all interventions reduce the risk. A backup is only worth something if the restore has been tested: that is why we put it in the calendar.
We do not promise load times or conversion rates: they also depend on the theme, images and plugins. We would expect a store that is more stable at peak times, outages flagged by a system rather than by customers, and a named person in charge with response times set out in writing.
This scenario is part of our managed VPS server and managed hosting services. If the store also needs rebuilding, see our e-commerce development service.
What companies ask us most often about moving to managed cloud.
Tell us your platform, current hosting and traffic peaks. We will tell you how we would move the store and what would change.