Managed WordPress: What to Verify in the First Week

The migration completed on a Friday and the site was faster. On the following Wednesday a product launch took it down for forty minutes. The managed plan had a PHP worker limit that nobody had read, the object cache was enabled but not configured for the site's table prefix, and the staging environment that the sales call promised was an add-on on a higher tier. The hosting was not bad. The verification had not happened.

Managed WordPress hosting is sold as a bundle: the platform, the updates, the cache, the backups and the support. The bundle is real, and the boundary around it is also real. The first week after onboarding is when both become visible, and it is the only week when the site is calm enough to test them without a customer noticing.

The checks below are ordered by how expensive the surprise is. None of them requires the host's cooperation beyond the access you already have, and all of them produce a fact you can write down.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The checklist is vendor-neutral; the links at the end are for two managed options that make different trade-offs.

A managed plan is an environment plus a boundary

The environment is what the host runs: the web server, PHP, the database, the cache layer, the CDN and the backup system. The boundary is what the host does not let you do: install certain plugins, run long processes, use arbitrary PHP extensions, send mail directly, or open a shell.

Most onboarding calls spend their time on the environment and skip the boundary. That is backwards for the first week, because the boundary is what breaks on the day the site gets busy. A plugin that needs a specific extension, a cron job that runs longer than the process limit, a mail plugin that is blocked by the platform: each is a boundary, and each surfaces at the worst possible moment.

Write down what you verified and what you could not. The list becomes the first page of the runbook and the basis for the conversation with support when something fails.

Verify the runtime before trusting the site

Start with the versions and the access. The PHP version should be current and supported, with the extensions the site needs: gd or imagick for image processing, intl for some plugins, redis or memcached for the object cache, zip for plugin uploads. The database version should be one the host supports and the site's plugins expect.

wp --info
wp core version --extra
wp db query "SELECT VERSION();"
wp plugin list --status=active --fields=name,version
wp cache type

The wp --info output includes the PHP binary and version, which is the fastest way to see whether the site is running on the version the panel claims. wp cache type tells you whether an object cache is active, and which backend it uses. If the answer is "none" on a managed plan that advertises Redis, the cache is not configured for this site.

Then the limits. PHP workers, memory, execution time, disk, inodes and database size are the numbers that decide whether the launch survives. Ask support for the plan's limits in writing, and test the process limit with a long-running WP-CLI command or an import. A host that cannot tell you the PHP worker count is a host that has not thought about the question.

Access is the other half. Does the plan include SSH, WP-CLI, Git deployments or only a panel and SFTP? A managed plan without a shell is still usable, but it changes how updates, backups and diagnostics are done. The answer belongs in the runbook, because the recovery steps are different with and without a shell.

Verify the backup before you need it

A managed backup is a feature until you know its shape. Four questions: where does the copy live, how long is it kept, who can run the restore, and what does the restore actually include? The answers decide whether the backup is a rollback for a bad update or a recovery from a lost account.

Run a restore in the first week. Restore into staging, or ask support to restore a copy to a temporary environment. Time it. Check that the database and the files come from the same moment, that uploads are present and that the site logs in. The restore drill is the same exercise; the point here is to do it while the migration is fresh and support still remembers the ticket.

Then check the off-host question. A managed backup usually lives on the host's infrastructure, which is the same commercial relationship as the site. That is fine for a bad update and not enough for an account suspension or a provider failure. Keep an independent copy, whether that is a bucket you own or a second backup service, and note the difference in the runbook.

Verify the edges: DNS, TLS, CDN, WAF and mail

Managed hosts often want the DNS pointed at their nameservers, which moves the zone and the mail records with it. That is convenient and it is also the step where email breaks. Before the change, export the zone. After the change, verify MX, SPF, DKIM and DMARC, and send a test message from the site to a mailbox at a different provider.

TLS should be automatic and renewable. Check the certificate chain and the expiry date, and confirm that the redirect from HTTP to HTTPS is a single 301 rather than a chain. The CDN and WAF in front of the site should be tested with a real request from outside the host's network, because an internal check can bypass the edge entirely.

Mail is the edge most likely to be restricted. Many managed platforms block direct SMTP to prevent spam and require a transactional provider. That is a reasonable policy and it needs a plugin or an API key. A site that cannot send a password reset is not fully migrated, and the failure is silent until someone tries to log in.

Verify the contract and the exit

The contract is where the first week's most expensive surprises live. Visitors, page views, bandwidth, PHP workers, disk, database size, staging refreshes, backup retention and support response time all have limits, and the overage terms are often less generous than the plan page suggests. Read them and write the numbers into the runbook.

Two clauses deserve particular attention. The first is what happens at the limit: does the site slow down, get throttled, or get suspended? The second is the exit: can you export the database and the files without a support ticket, and can you move the domain? A host that makes the export difficult is a host that has decided the exit is a retention strategy.

The exit test is simple and worth doing in the first month. Export a database dump, download a file archive and confirm the zone can be exported. If any of the three requires a ticket that takes a week, the site is less portable than it looks. Portability is not a feature you need until you need it, and then it is the only feature.

Verify the access model

Managed plans vary in who can log in and what they can do. Check whether the host's dashboard supports separate accounts, single sign-on, two-factor authentication and role separation between billing and technical contacts. Check whether SSH keys can be scoped, and whether staging has its own credentials rather than sharing production's.

Then the plugin policy. Some managed hosts restrict which plugins can be installed, either for performance or for security. The restriction is a feature until it blocks the one plugin the site needs. Test the key plugins before the migration, and get the list in writing if the host maintains one.

The access model also includes the host's own staff. Ask who can access the site's files and database, under what conditions, and whether that access is logged. The answer is part of the security posture, especially for a store that holds customer data.

The first-week checklist

1. Record PHP, database and WordPress versions, plus the extensions the site needs.
2. Confirm the object cache is active and configured for this site.
3. Get the plan limits in writing: PHP workers, memory, disk, visitors, overage.
4. Confirm SSH, WP-CLI or the panel-only workflow, and document the recovery steps for it.
5. Run a restore into staging and time it; ask about retention in days.
6. Verify DNS, TLS, CDN, WAF and mail, including a password reset to an external mailbox.
7. Export a database dump and a file archive, and locate the zone export.
8. Review the host's plugin policy, access model and support escalation path.

Two managed options illustrate the trade-off. Pressable is built around WordPress with staging and a panel that exposes the environment, which suits a store that wants the platform managed but still wants a shell. WordPress.com on a plan that allows plugins is more opinionated and more locked down, which suits a site that would rather not have the options.

Where managed hosting is the wrong purchase: a site whose owner enjoys the server, updates weekly and already runs a staging environment and an off-host backup. There, the premium buys convenience rather than capability, and the money may be better spent on a second backup destination. The decision rule is the one this article keeps returning to: the plan is worth it when the boundary matches the site's needs, and the only way to know is to test the boundary in the first week.