TL;DR
- A conferencing provider, a client since 2019, had six corporate sites on self-managed servers with PHP upgrades done by hand on refreshed staging copies, a 2020 compromise restored from backup, and a leftover malicious script found in a theme file months later
- In January 2024 the marketing manager proposed managed WordPress. The IT department's questions followed: which ports would be open, whether the security headers would carry over, what happened to the dedicated IP, and how the sites could send mail when the SPF record was out of lookups
- We answered in writing, moved the server-level headers into the application layer, ran a test migration with a performance comparison, and arranged DKIM signing on a custom selector so nothing was added to SPF
- The May 2024 server migration ran against a DNS runbook the corporate technical director reviewed in advance
- In May 2026 the redesigned corporate site launched on the same platform with the old site kept in staging as the fallback the client asked for, followed by an India-region site and a new product site
- On October 22, 2026, when a critical PHP vulnerability was disclosed, all six sites were patched, verified, and confirmed to the client in writing the same day
A Marketing Team That Wanted Managed Hosting and an IT Team That Had Questions
The provider's websites had always been the marketing department's responsibility on infrastructure the IT department owned. That worked until it did not. In December 2020 one site was compromised and restored from backup; in January 2021 we found a malicious script still sitting in the theme's header file, there since the previous October. PHP upgrades across five sites in 2020 and 2021 each meant a refreshed staging copy and a minimum of six hours of testing per site.
By January 2024 the marketing manager wanted the sites on managed WordPress. The IT department wanted to know what that meant. Their questions were the right ones, and they came from a corporate technical director, not a marketing contact.
What IT needed answered:
- Which ports would be open on the new environment
- Whether the HTTP security headers set at the server level would still be present
- What would happen to the dedicated IP the sites had always used
- What operating system and server stack the managed platform ran
- How the sites would send authenticated mail when the company's SPF record was already at its ten-lookup limit
Answer Everything in Writing, Then Migrate on a Runbook
Ports, headers, and IP. We documented the port surface of the managed environment and explained that a dedicated IP follows the certificate and domain, so moving them simply produces a new one. The security headers that had been set in the server configuration were moved into the site's own configuration and theme, so they travel with the site. A scanner the IT team ran still could not see some headers that were present; we added them at a second layer until it could.
The SPF problem. Adding the managed host's mail servers to SPF would have pushed the record past its lookup limit and broken authentication for the company's real mail. Instead we confirmed with the host that it could sign outbound mail with DKIM on a custom selector, so each site's transactional mail would authenticate without touching SPF at all. The IT team received the keys when the first site was ready.
Test first. A test migration of one site with a before-and-after performance comparison went to the marketing and IT teams before anyone committed. The internal meeting in March 2024 ended with everyone on board.
Migrate on a runbook. The corporate technical director asked for a list of every public DNS record that would change and how. We supplied it; the network team reviewed it; the migration ran on the scheduled day in May 2024 with the company's support site moved first as a rehearsal.
Relaunch with a fallback. Two years later the marketing team had a redesigned corporate site ready on a staging URL and wanted it live on a Tuesday, with one condition: a way back to the old site "in the event we need something from the old site." We launched the new site, moved the previous version into the staging environment under the old credentials, and invoiced the migration. An India-region site and a new product site followed on the same platform.
Patch day. On October 22, 2026, a critical PHP vulnerability was disclosed. All six sites were patched and verified that day, with a written note to the client listing each one. PHP major-version upgrades for the sites still on an older release were quoted the following week.
What the Provider Has
- Six sites on managed WordPress with the IT department's requirements met and documented, not waived
- Mail authentication that did not touch SPF, through DKIM on a custom selector
- A corporate relaunch with a real fallback, the old site preserved in staging on request
- Same-day response to a critical vulnerability across every site, confirmed in writing
- Seven years of history in one support system, from the 2020 compromise to the 2026 patches
The relationship is with marketing. The credibility is with IT. Both matter.
Frequently Asked Questions
What does an IT department need to approve a managed WordPress migration? The port surface, the handling of the dedicated IP and certificates, where security headers are set, the server stack, and how mail will authenticate. Answer each one in writing before the migration, not during it. The questions are reasonable, and the answers are the migration plan.
How do you send authenticated mail when SPF is out of lookups? With DKIM. SPF has a hard limit of ten DNS lookups, and large companies hit it. A host that signs outbound mail with DKIM on a custom selector lets each site authenticate without adding anything to SPF. DMARC alignment is satisfied by either, so this is a clean solution, not a workaround.
Why keep the old site after a relaunch? Because someone will need a paragraph, an image, or a PDF from it in the first month. Moving the old site into the staging environment keeps it reachable with the old logins and costs nothing. It also makes rollback a DNS change if the launch goes wrong.
How fast should a critical PHP vulnerability be patched? The same day if the sites are on a managed platform where the fix is a version switch. For this client, six sites were patched and verified on the day of disclosure. The slower work, upgrading sites still on an end-of-life PHP release, was quoted separately because it needs testing.
Does managed hosting replace an IT department? No. It gives the IT department a vendor whose answers it can audit. The provider's IT team still owns DNS, mail, and the corporate network; the managed host owns the servers; we own the sites and the coordination between the two.