An enterprise WordPress decision usually starts with a performance question and ends with a contract. The site may be fast, but the security team wants evidence, legal wants a DPA, procurement wants a three-year price, and the on-call team wants to know who owns the 2 a.m. page. A host that cannot answer those questions is not enterprise-ready, regardless of its TTFB.
This playbook is written for the cross-functional team that has to make the decision: engineering, operations, security, legal, and the business owner. It covers the operating model, the controls to verify, the RFP questions, and a 12-week rollout that keeps the existing site live until the new one is proven.
- Define ownership first. Host, agency, and internal team each own a layer; write it down.
- Separate environments. Development, staging, and production with controlled promotion.
- Verify the controls. SSO, audit logs, access review, vulnerability management, incident notification.
- Read the SLA. Credits are not damages; exclusions and measurement matter more than the percentage.
- Pilot before the estate. Migrate one representative site, prove the model, then scale.
- Plan the exit. Data export, DNS control, and contract termination should not be an afterthought.
What “enterprise” actually means
Enterprise hosting is a bundle of guarantees and interfaces. The infrastructure is part of it, but the differentiators are operational: a named support path, a documented incident process, security attestations, environment controls, and a contract that procurement can accept. A high-traffic site on a consumer plan is not enterprise hosting; a modest site on a platform with those controls may be.
There are three common operating models. In a managed platform, the host owns the stack and the enterprise team owns the application. In a cloud + agency model, the enterprise owns the cloud account and the agency operates WordPress on top. In a self-managed model, the enterprise owns everything and buys only infrastructure. Most enterprises choose one of the first two because the operational burden of the third is underestimated.
| Layer | Managed platform | Cloud + agency | Self-managed |
|---|---|---|---|
| Infrastructure | Host | Enterprise / cloud | Enterprise |
| WordPress core | Host (with app input) | Agency | Enterprise |
| Plugins / theme | Enterprise / agency | Agency | Enterprise |
| Security patching | Shared | Shared | Enterprise |
| Incident command | Host + enterprise | Agency + enterprise | Enterprise |
| Contract | Host MSA + DPA | Cloud + agency MSAs | Cloud MSA |
The controls to verify
Identity and access. SSO for the hosting panel, role-based access, least privilege, and a quarterly access review. Shared logins are an audit finding waiting to happen. Ask how team members are offboarded and whether the host supports SCIM or directory sync.
Environment separation. Development, staging, and production should be distinct, with a controlled promotion path. A staging environment that shares the production database is not a staging environment. Ask how code and content are promoted and whether production access is restricted.
Audit and logging. Panel activity, deployments, access changes, and security events should be retained and exportable. If the host only offers a 24-hour log view, that may not satisfy an incident review or a regulator. Confirm retention, export format, and whether logs can be sent to your SIEM.
Vulnerability and patch management. Ask who patches the OS, the web server, PHP, WordPress core, and plugins. The shared-responsibility boundary should be explicit. A host that patches the OS but not plugins is normal; a contract that implies otherwise is a problem.
Incident notification. Define what counts as a security incident, who is notified, how quickly, and through which channel. Test the path with a tabletop exercise before you need it.
Backups and recovery. Confirm retention, restore granularity, restore time, and whether backups are encrypted and stored separately. Test a restore, not just the backup job.
The SLA: read the footnotes
Most enterprise SLAs promise a monthly uptime percentage and service credits if it is missed. The credits are usually a percentage of the monthly fee, not compensation for lost revenue. The important details are the measurement method, the exclusions (maintenance, force majeure, customer-caused incidents), the claim window, and the support response targets.
A 99.99% commitment sounds strong until you read that it is measured monthly from a single region and excludes scheduled maintenance. Ask for the actual measurement methodology and the last 12 months of status history. A host that publishes an incident log is easier to trust than one that only publishes a percentage.
An SLA is not business continuity. Keep an independent backup, a documented manual failover, and a communication plan. If the host is the only copy of the site and the only runbook, the SLA is doing more work than it can.
The reference architecture
Governance is a chain, not a checkbox. A weak identity layer or an untested restore breaks the chain regardless of the host's uptime.
The shortlist, by binding constraint
WP Engine is the broad institutional fit: a mature platform, a large agency partner network, and procurement experience. It is a sensible default when legal and security need a known vendor and the application is conventional WordPress.
Kinsta is the performance-and-support fit: strong TTFB, a tight tail, and a support team that operates at the WordPress layer. It suits enterprises that want a managed platform without a heavy consulting relationship.
Rocket.net is the edge-performance fit: the fastest p75 TTFB in our cohort and an included enterprise edge. It is a strong choice when global delivery is the priority and the team can work within a narrower platform surface.
Cloudways can be an enterprise-adjacent option when the organization wants cloud-account ownership and has an operations team, but it requires more governance work from the buyer. It is not a turnkey enterprise hand-off.
The RFP questions that produce comparable answers
| Area | Question | Evidence |
|---|---|---|
| SLA | What is the uptime commitment, measurement method, and credit? | Contract language + 12-month status history |
| Support | What are the response targets by severity, and who is on call? | Support policy + escalation matrix |
| Security | Which controls are host-owned vs customer-owned? | Security questionnaire + shared-responsibility matrix |
| Identity | Is SSO available? How is offboarding handled? | Admin guide + access-review process |
| Logs | What is retained, for how long, and can it be exported? | Log schema + retention policy |
| Recovery | What is the restore RTO/RPO, and when was it last tested? | DR documentation + test report |
| Exit | How do we export data, DNS, and configuration? | Exit plan + data format |
| Commercial | What is the three-year price with overages and renewal caps? | Quote + contract redlines |
The 12-week rollout
Discovery and requirements
Inventory the estate, name the critical paths, define the security and procurement requirements, and agree on the decision criteria.
RFP and security review
Send the questionnaire, score the responses, review the contract, and shortlist two vendors. Do not skip reference calls.
Pilot build
Build one representative site on the chosen platform. Configure SSO, staging, backups, WAF, and monitoring. Run a restore test.
Migration and testing
Migrate content, test integrations, run a load test, and rehearse the cutover and rollback. Train the support team.
Cutover and stabilization
Move the pilot, monitor for two weeks, then plan the remaining sites. Hold a post-migration review before scaling.
The enterprise scorecard
- Availability and incident MTTR — measured against the SLA, with exclusions visible.
- Change failure rate — the share of deployments that require a rollback or hotfix.
- Restore test result — date, duration, and integrity, not just “backups enabled.”
- Access review completion — percentage of accounts reviewed on schedule.
- Security findings and time to remediate — by severity.
- Cost per site and cost per environment — including unused staging environments.
An enterprise host is a long relationship. Choose the vendor whose operating model matches your team, whose contract you can live with, and whose incident behavior you have verified. The fastest benchmark is not worth a support boundary that leaves your team alone at the worst moment.