How to Evaluate Hosting Backups, Migration, and Support
A hosting plan can advertise backups, migration, and expert support while leaving the most important operational details undefined. The useful question is not whether a feature appears in a comparison table. It is whether the feature can recover your specific website, under your access constraints, within the loss and downtime you can accept.
This guide is a purchasing framework for a small website, WordPress installation, or lightweight web application. It does not rank providers. Provider features, plan limits, regional availability, and support policies change, so verify the current plan page, documentation, and contract before purchase.
1. The 60-second evaluation table
| Claim | Minimum evidence to request | Warning sign |
|---|---|---|
| “Automatic backups” | Frequency, retention, scope, storage location, encryption, and restore path | A checkmark with no retention or restore documentation |
| “One-click restore” | What is restored, where it is restored, and whether it overwrites production | No explanation of database consistency, files, or rollback |
| “Free migration” | Included sites, data types, access requirements, exclusions, validation, and DNS responsibility | “We move everything” without a written scope |
| “24/7 expert support” | Channels, plan restrictions, response targets, escalation path, and scope | No boundary between platform faults and application code |
| “Managed security” | Which layer is managed and who handles compromised plugins, credentials, and content | Language that implies the site owner has no security duties |
If you cannot find written answers, ask support before buying and save the response with the date and plan name. A sales chat is evidence of what was said, but the formal service terms and current documentation should control your final decision.
2. Evaluate backup frequency, retention, and storage
Start with the data you can afford to lose. A site updated once a month has a different recovery-point requirement from a store receiving orders every hour.
Ask these questions:
- How often are files captured?
- How often is the database captured?
- Are files and database captured as one consistent recovery point?
- How many restore points are retained?
- Does retention change by plan, region, account status, or server state?
- Are backups stored on the same server, elsewhere in the same provider, or in an independent location?
- Can you download a complete backup without opening a support ticket?
- What happens to backups after cancellation, non-payment, application deletion, or server deletion?
For WordPress, a file-only copy is normally incomplete. WordPress documentation separates the site into files and a database and states that a typical complete restore needs both. The files include themes, plugins, uploads, configuration, and other assets; the database contains posts, settings, users, and application data. Review the WordPress backup overview and the separate file-backup explanation.
A provider-managed backup is useful, but it should not be your only recovery path. WordPress recommends keeping multiple recent copies in different locations, and some provider documentation also advises maintaining a local copy separate from automatic platform backups. Treat this as risk separation rather than a magic number: a backup controlled by the same account, billing state, and platform can share the same failure mode.
A practical retention test
Write down three incidents and check whether the published retention would cover them:
- An editor deletes a page and notices within two hours.
- A plugin corrupts data and the damage is noticed four days later.
- A compromised administrator account makes gradual changes that are discovered several weeks later.
The correct retention is the one that preserves a clean point before your realistic detection delay. More restore points are not automatically better if you cannot identify which one is clean or if all copies are stored behind the same compromised credentials.
3. Verify restore access, cost, and testing
A backup is not a recovery process until you know how to restore it.
Confirm:
- whether restores are self-service or require support;
- whether restoring files and database can be done separately;
- whether the restore targets production, staging, a new server, or a downloadable archive;
- whether the current site is overwritten;
- whether the restore changes IP addresses, credentials, URLs, or environment configuration;
- whether restore attempts or retained copies cost extra;
- whether support will help when a self-service restore fails; and
- whether you can test a restore before an incident.
Do not accept “one click” as a substitute for these details. A restore can succeed technically while leaving the wrong site URL, stale credentials, missing cron jobs, broken email delivery, or an incompatible runtime.
Provider documentation can reveal important distinctions. Cloudways, for example, documents backup restoration separately from server recovery or rebuild and notes that recovery behavior depends on the product and available backup. That is a useful reminder to ask what object is being recovered: an application, a server, or an account-level service. Read the current Cloudways recovery documentation.
The strongest pre-purchase evidence is a restore rehearsal. Use a non-production destination, record the start and finish time, verify the content and administrative login, and document anything that required manual repair. If the provider does not allow a safe test, lower your confidence and preserve an independent export you can restore elsewhere.
4. Define the migration scope line by line
“Website migration” can mean a plugin copy, a database import, a full account transfer, or a technician-assisted project. Do not infer the scope from the word migration.
Use this inventory:
| Component | Ask whether it is included | Validation after transfer |
|---|---|---|
| Web files and uploads | Hidden files, custom directories, large media, permissions | Compare counts and sample files |
| Database | All tables, large tables, serialized data, database users | Login, content, settings, and application actions |
| URLs | Home/site URL, serialized values, hard-coded paths, redirects | Crawl old and new URLs; inspect media and canonical tags |
| Mailboxes, aliases, forwarding, SMTP, DNS records | Send and receive from independent accounts | |
| DNS | Zone records, TTL planning, nameserver or record changes | Resolve from multiple networks and verify old records are preserved |
| TLS | Certificate issuance, validation method, renewal, redirect to HTTPS | Test HTTPS, hostname coverage, mixed content, and renewal ownership |
| Cron and workers | WordPress cron, system cron, queues, scheduled scripts | Run or observe each scheduled job |
| Server configuration | PHP/runtime versions, extensions, rewrite rules, limits | Compare configuration and application logs |
| External services | CDN, object storage, payment, webhooks, APIs | Test each integration with non-destructive actions |
WordPress migration guidance explicitly distinguishes files, database configuration, site URLs, media links, and permalink behavior. It also recommends backing up the files and database before a move. Use the official WordPress migration documentation as a technical baseline.
A provider may require temporary access to the old host, WordPress administrator, SFTP/SSH, database, DNS provider, or registrar. Ask how credentials are collected, who can access them, how long they are retained, and when you should rotate them. Never send long-lived credentials through an unapproved channel merely because a migration form requests them.
For the execution sequence, use the website migration checklist to build and validate the destination before moving traffic.
5. Separate server support from application support
Managed hosting does not normally mean that the provider becomes your developer.
A useful responsibility boundary has at least four layers:
- Infrastructure: physical host, virtualization, network, and storage service.
- Platform: operating system, web server, database service, caching layer, control panel, certificates, and provider tooling.
- Application: WordPress core, plugins, themes, custom code, database queries, forms, integrations, and content workflows.
- Business operation: DNS ownership, email accounts, user access, compliance decisions, vendor relationships, and incident authority.
Read the provider's scope-of-support page, not only its marketing page. Current official examples make the boundary visible: WP Engine documents support for its platform and certain WordPress configuration issues while excluding custom code, design, many plugin/theme bugs, DNS changes, and inbound email. Kinsta similarly documents platform assistance and migration help while stating that code editing, site functionality changes, SEO work, and other development responsibilities remain with the customer or developer. These examples do not prove that one provider is better; they show why “expert support” must be translated into a written responsibility matrix. Review WP Engine's current scope and Kinsta's current managed WordPress support scope.
If your real need is application development, budget for a developer or internal owner. If your need is a documented platform restore, choose a provider whose support scope clearly includes that operation.
Use the hosting model comparison to decide which responsibilities you are prepared to keep.
6. Ask these ten questions before purchase
- What exactly is included in a backup: files, database, configuration, email, DNS, and external storage?
- What are the backup frequency and retention for this exact plan and region?
- Can I download a complete, provider-independent backup without support?
- Can I restore to staging or a separate environment without overwriting production?
- What migration components and number of sites are included, and what is excluded?
- Who validates the migrated site, and what evidence marks the migration complete?
- Who changes DNS, issues TLS certificates, and verifies email after the cutover?
- Which platform problems will support investigate, and which application problems are out of scope?
- Are any channels, response targets, migrations, restores, or escalations restricted by plan?
- What happens to my site and backups after cancellation, failed payment, deletion, or account termination?
Record the provider's answer, the source URL, the plan, the region, and the access date. Recheck before renewal or a major migration because the answer may change.
7. Watch for common marketing red flags
Be cautious when you see:
- “daily backups” with no time, timezone, or retention period;
- “off-site” with no explanation of account or provider separation;
- “free migration” with no supported application list or exclusions;
- “zero downtime” without a traffic-freeze and rollback procedure;
- “unlimited support” without supported channels and application boundaries;
- “fully managed” without a responsibility matrix;
- “instant restore” without an overwrite warning;
- screenshots that do not identify the current plan or product;
- a feature comparison that conflicts with the formal documentation; or
- a sales answer that cannot be found in the contract or support policy.
A missing detail is not proof of bad service. It is a reason to ask a precise question and lower your confidence until the answer is documented.
8. Build a reader responsibility matrix
Use a matrix before you buy:
| Task | Provider | Site owner | Developer or specialist | Evidence |
|---|---|---|---|---|
| Infrastructure availability | Status/SLA or service terms | |||
| Server and platform patches | Scope-of-support documentation | |||
| WordPress core updates | Plan documentation | |||
| Plugin and theme updates | Update policy and exclusions | |||
| Backup creation | Schedule and retention page | |||
| Restore decision and validation | Restore runbook | |||
| Custom-code repair | Support exclusions | |||
| DNS and TLS cutover | Migration scope | |||
| Email migration and delivery | Email scope and test plan | |||
| Incident communication | Support channels and account roles |
Do not leave a row blank. If two parties appear responsible, name who decides and who executes. Shared responsibility without a named owner often becomes no responsibility during an incident.
9. Complete a decision worksheet
For each candidate plan, record:
- exact plan, region, billing term, renewal date, and taxes;
- backup scope, frequency, retention, location, download method, and restore method;
- migration scope, exclusions, access required, validation owner, and rollback approach;
- support channels, hours, plan limitations, escalation path, and application exclusions;
- work you still need to perform or buy elsewhere;
- maximum acceptable data loss and downtime;
- result of a non-production restore or migration rehearsal; and
- the date each fact was last verified.
Then convert the missing work into cost. The Small Website Hosting Total Cost Calculator can combine recurring add-ons, migration expense, and maintenance time without transmitting or saving your figures.
When the destination is selected, use the printable WordPress Pre-launch Checklist to turn the responsibility matrix into launch evidence.
10. Make the decision from recoverability, not feature count
The better plan is not the one with the longest feature table. It is the plan for which you can answer:
- What will be backed up?
- How far back can I recover?
- Can I obtain a copy outside the platform?
- How will I test a restore?
- What exactly will be migrated?
- Who owns DNS, TLS, email, and validation?
- What will support do when the application fails?
- What remains my responsibility?
If a managed platform does not reduce the operational risks that matter to you, review when not to pay for managed cloud hosting. If it provides a tested recovery path and takes ownership of work you cannot reliably perform, the premium may be justified.
The conclusion should be reproducible: another person should be able to read your worksheet, find the evidence, and understand why the plan was chosen without relying on a sales slogan.