WordPress hosting for sites outgrowing SiteGround.
A SiteGround site usually arrives with SG Optimizer woven through it: rewritten URLs, generated image formats, and a caching layer that has to come out before another one goes in.
A shared-hosting site has years of accumulation in it.
The database and files copy fine. The work is in the layers that were added on top of them over several years.
SG Optimizer, removed in the right order
The plugin rewrites URLs, generates alternative image formats and manages a cache layer simultaneously. Removing it carelessly leaves broken image references, so it comes out in sequence rather than in one step.
Generated image formats
Alternative image versions created alongside your originals are referenced from content and templates. We make sure equivalents exist here before anything stops serving them.
Accumulated .htaccess rules
Years of shared hosting leaves redirects, protection and caching rules in one file. Those are read, separated by purpose and reimplemented rather than copied wholesale into a stack that does not use them.
Cron that ran on the host's schedule
Shared hosting often replaces WP-Cron with a system cron on a fixed interval. That entry belongs to the host, so it is moved to a platform scheduler rather than left to stop.
A database that has been shared
Long-lived shared MySQL means table prefixes, extra users and leftovers from installs that are no longer there. The import gets checked rather than assumed.
Untangled first, then moved.
The order matters more here than on a managed host. Pulling the optimisation layer at the wrong point is what produces a site full of missing images.
- Optimiser layer unwound in sequence, not in one action
- Staged copy on a temporary domain for review
- Cutover at a time you choose
- Old host left running until you confirm
Off shared infrastructure.
The largest single change moving from shared hosting is that your site stops competing for resources with sites you have never heard of.
What we change when a site arrives from SiteGround
These are the specific things a SiteGround site needs attention on, as opposed to a straightforward copy of files and database.
| Setting | What we do | Why |
|---|---|---|
| SG Optimizer | Removed in sequence, with image references checked at each step | It touches URLs, image formats and caching at once, so pulling it in a single action is exactly what leaves a site full of missing images. |
| Generated image variants | Regenerated here before the rewriting stops | Content referencing an alternative format that no longer exists renders as a broken image, and nobody sees it until somebody loads that page. |
| .htaccess rule set | Read, categorised by purpose and reimplemented as edge and server rules | Copying an accumulated Apache config into a different stack carries forward rules that nobody has understood for years. |
| Cron | Moved from the host's system cron to a platform scheduler | A shared host's cron entry is not part of your site, so scheduled work simply stops on the day you leave and nothing reports it. |
| Database import | Prefixes and leftover tables checked rather than assumed | A long-lived shared database usually still holds tables belonging to installs that were removed years ago. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
What happens to SG Optimizer?
Will my generated image formats survive the move?
What about my .htaccess file?
My scheduled posts run on a host cron. Will they still work?
Do you handle the DNS change?
Leave shared hosting without leaving your images behind.
Free migration, the optimisation layer unwound in order, and a preview before anything switches.