Choosing web hosting: requirements, costs and a migration checklist
Choose hosting from your website’s actual needs: static pages, WordPress, forms, backups and ongoing responsibilities, with portfolio examples.
Choose hosting by listing what your website needs to run: pages, images, a content editor, a database, forms and email. These services may live in different places. A low headline price tells you little until you know the scope and who will operate it.
Match the architecture to the workload
The LR Studios catalogue uses HTML, CSS and Bootstrap. The rebuilt Sanegon website uses a static architecture without a database or content administration layer. MAHVU, by contrast, uses WordPress and a form through which members publish news.
These are different hosting requirements, not evidence that one provider is always best. A static site still needs a publishing process. WordPress needs compatible server software, database management and a complete backup. A contact form may depend on a separate processing or email service.
Compare the complete offer
Ask about renewal pricing, storage, transfer limits, email, backups and support. Find out what happens when a limit is reached: extra charges, throttling or suspension. Keep the dated terms that informed your decision.
Shared hosting can simplify administration. A VPS or dedicated server offers control but brings operating responsibilities unless management is explicitly included. A cloud platform can simplify deployment while still requiring attention to usage and costs. Check whether any free plan permits your intended commercial use.
Test performance rather than relying on labels
If most customers are in France, include tests from that region and on mobile. Distinguish a slow HTML response from a large image or an external script. Moving hosts does not automatically fix the latter.
Ask how page caching works and how updates invalidate old content. Test an important service page and a contact journey, not only the home page. Use the Core Web Vitals guide to interpret the results.
Check restoration before you need it
A backup should include the files, database, media and configuration needed to recover the service. A code repository alone will not restore WordPress posts or store orders. Set frequency according to the amount of new data the business could afford to lose.
Restore into a separate test environment and record how long it takes. France's CNIL continuity guidance stresses preparation and testing. Identify who can recover the site if the usual developer is unavailable.
Prepare the move carefully
Inventory DNS records and accounts. Build a working copy on the new host and check pages, assets, HTTPS, redirects and form delivery. Preserve required email records when changing DNS. For a site receiving new data, plan the final synchronisation.
Keep the previous host available during verification and retain a rollback path. DNS propagation depends on caching; an arbitrary waiting period is not enough to decide that the old site can be removed.
A useful handover includes owner-controlled access, a publishing procedure, a tested recovery process and written responsibilities. Include these in the maintenance scope, rather than treating hosting as a purchase that needs no further attention.