Refactoring a 74-site WordPress fleet — 59 of them on one AWS EC2 + WHM/cPanel host — to AWS-native serverless, one site at a time, inside the same AWS account. iSimplifyMe-built. iSimplifyMe-operated.
What is the AWS Modernization case?
iSimplifyMe operates a 74-site WordPress fleet, 59 of those sites on one AWS EC2 host running WHM/cPanel, and is refactoring the fleet site by site into AWS-native serverless: Next.js on AWS Lambda behind CloudFront, with S3, DynamoDB, and SES. It is an intra-AWS modernization — iSimplifyMe has been on AWS for years, and the move from EC2 to Lambda stays inside the same account perimeter under the AWS 7 Rs Refactor pattern, with Apex Architecture as the control plane across 31 active tenants. Eight of the 28 clients on the public roster run on the serverless stack as of September 2026; 59 sites remain on the legacy host, whose EC2 compute billed roughly $105 in August 2026 and runs around the clock regardless of traffic. A refactored site’s compute is pay-per-request and approaches zero when idle.
The setup
The fleet is made up of client and first-party websites: healthcare practices, law firms, real estate and mortgage, specialty trades, and iSimplifyMe’s own products. The WordPress side of that fleet is 74 sites; 59 of them run on one AWS EC2 instance in us-west-2 (Oregon) with WHM/cPanel as the control panel and MariaDB behind it. iSimplifyMe has been on AWS for years, but the EC2-plus-cPanel pattern carries the operational weight of on-prem hosting: an idle compute floor, one shared OS image, WHM/cPanel licensing, no CloudWatch-native observability per site, and a control panel the AWS BAA does not cover.
The mandate: move the fleet from EC2 to Lambda, site by site, without leaving the AWS account perimeter iSimplifyMe has operated within for years.
Why this is harder than it looks
Idle EC2 compute floor
EC2 instances run 24/7 regardless of per-site traffic. On a host carrying 59 sites, most of which get fewer than 1,000 requests a day, iSimplifyMe pays for compute that sits mostly idle. The us-west-2 EC2 line ran roughly $105 in August 2026 for that one host, billed on demand and around the clock whether or not anyone visits. Refactor to Lambda collapses this floor to pay-per-request.
WHM/cPanel licensing and OS coupling
WHM/cPanel licensing adds a cost layer the serverless target does not carry. The 59 sites on the host also share one OS image and one MariaDB server, so a kernel update, a PHP version bump, or a cPanel maintenance window is host-wide by design. The target gives each site its own CloudFront distribution, its own ACM certificate, and its own Lambda function — no shared OS, no per-server licensing, and no maintenance window shared across a host.
No CloudWatch-native observability per site
cPanel writes its logs to local rotation on the EC2 host, outside CloudWatch. Each site’s Lambda function logs to CloudWatch by default; Apex Architecture adds persistent uptime time series in DynamoDB, response-time rollups, and surfaced charts in a per-client dashboard. The uptime series comes from an SST cron that pings every active tenant domain every 5 minutes, so it exists per site rather than per host.
cPanel sits outside the AWS BAA
The AWS BAA covers AWS services, not third-party software installed on them, and cPanel is third-party software. The serverless target runs on HIPAA-eligible AWS services (Lambda, DynamoDB, S3, SES, Bedrock), so a healthcare or legal engagement can be taken on the same pattern; the shared cPanel host cannot make that claim.
Per-site refactor pattern (AWS 7 Rs: Refactor)
| Legacy (AWS EC2 + WHM/cPanel) | Refactor target (AWS-native serverless) |
|---|---|
| WordPress (PHP) + MariaDB on EC2 | Next.js 16 (App Router) + TypeScript on Lambda |
| One EC2 instance in us-west-2 + WHM/cPanel | AWS Lambda + CloudFront (per-site distribution, ACM cert) |
| Per-site Apache vhost on shared EC2 | Per-site CloudFront distribution (isolated per client) |
| WordPress media library on EC2 disk | Amazon S3 + CloudFront origin |
| MariaDB on EC2 (wp_options + wp_posts) | Content as versioned Markdown/MDX in the site repository; operational data in Amazon DynamoDB (single table, composite-key isolation) |
| WordPress contact form | Apex API endpoint + DynamoDB + Amazon SES |
| WordPress editor + Yoast SEO | Apex content pipeline (MDX) + AEO scanner |
| cPanel cron / WP-Cron on EC2 | AWS Lambda + SST cron (uptime probes every 5 minutes) |
| cPanel local log rotation | Amazon CloudWatch Logs (per-site Lambda logs) |
| cPanel email / shared SMTP | Amazon SES with verified domain identity |
| 24/7 EC2 compute floor | Pay-per-request Lambda (near-zero idle) |
The application framework also modernizes: WordPress (PHP/jQuery) becomes Next.js 16 with React Server Components and TypeScript, deployed to Lambda through SST v3 and OpenNext. Plugin-driven security patching and PHP version-bump risk retire as the refactor lands.
Build log
- Phase 0
Apex control plane live (March 2026)
The multi-tenant control plane that makes per-site refactor economically viable at fleet scale. Nine functional modules per tenant (Bot Analytics, Search Performance, Site Health, Support + Changes, Content Pipeline, AEO Scores, Billing, SOW Generator, Admin). Eleven Cloudflare Workers streaming bot-hit events into DynamoDB. An SST cron firing uptime probes every 5 minutes against every active tenant domain — 31 active tenants as of September 2026. Production at apex.isimplifyme.com.
- Phase 1
First wave of client refactors (April–May 2026)
The first client sites refactored to AWS-native serverless validated the pattern. Each per-site refactor follows the same shape: Next.js scaffold, content port, Apex tenant record, CloudFront distribution, ACM certificate, SES verified domain, AEO compliance pass. Roughly one to two weeks per site once the pattern is in place.
- Phase 1.5
AI-augmented support pipeline live (April 2026)
SQS-driven Lambda executor calls Claude on Amazon Bedrock to analyze Tier-1 support tickets (text changes, contact-info updates, small fixes), generates a code patch, opens a GitHub pull request on the client repository, and notifies the admin. Tier-1 tickets resolve with a human approval gate on the merge. Production ticket volume is small; the pipeline is validated end-to-end.
- Phase 1.7
Rebuilds and migrations on the pattern (through September 2026)
The pattern is now the default for new client sites and migrations. An ophthalmology practice was rebuilt and launched on it in August 2026; a regulated law-firm fleet was built on it in the firm’s own AWS account. A mortgage-and-real-estate site was migrated from WordPress to Next.js, a physician’s practice site was migrated to Next.js, and a specialty-trades site was rebuilt on it in 2026. Eight of the 28 clients on the public roster run on the serverless stack as of September 2026.
- Phase 2
The remaining fleet (in progress)
Fifty-nine sites still run on the legacy EC2 host in us-west-2, hardened in the meantime: Cloudflare in front of every site, per-account CPU isolation, automated bans for scanners, and a one-minute canary. Each subsequent refactor deploys onto the Apex control plane that already exists, on a schedule agreed with each client around content cutover and a DNS switchover window.
- Phase 3
Decommission legacy EC2 (post-cutover)
Once the fleet is fully refactored, the legacy us-west-2 EC2 host and its WHM/cPanel accounts are decommissioned. The roughly $100-a-month EC2 compute floor disappears, replaced by per-site Lambda invocation costs that scale with real traffic. This program is part of the evidence base for a future AWS Migration Competency application.
Built and operated, not delivered.
Most cloud-migration engagements end with a runbook for the client’s internal team to execute.
This one is an ongoing refactor program iSimplifyMe runs against its own fleet in production. The same pattern runs in a client-owned account; the regulated law-firm fleet study documents it. Eight roster clients on the serverless stack, 59 sites still on the legacy host, the Apex control plane firing uptime probes every 5 minutes across 31 active tenants. When Phase 3 lands, the legacy us-west-2 EC2 host is decommissioned, and with it the shared OS image, the WHM/cPanel accounts, and the roughly $100-a-month compute floor.
Frequently asked questions
How is this different from a typical AWS migration project?
A typical AWS migration moves workloads into AWS from on-prem or another cloud. This is not that. iSimplifyMe’s 59-site host already runs on AWS, on EC2 with WHM/cPanel — the modernization moves from EC2 to Lambda behind CloudFront within the same AWS account. Same IAM perimeter, same CloudTrail, same Cost Explorer, same operational team. The architectural pattern changes; the AWS relationship does not.
Why refactor instead of rehost or replatform?
Rehost, the lift-and-shift, keeps the EC2 cost model: a 24/7 compute floor regardless of traffic. Replatform, EC2 to a container service, removes server management but keeps always-on compute. For a host carrying 59 sites where most get fewer than 1,000 requests per day, Refactor (per the AWS 7 Rs framework) is the option that collapses the idle compute cost while keeping the fleet inside the AWS account. Lambda charges per request, so the cost floor approaches zero when sites are idle and scales linearly with real traffic.
Who operates the refactored sites?
iSimplifyMe. Each refactored site deploys as a Next.js application on AWS Lambda behind CloudFront through SST v3 and OpenNext. The operational control plane — Apex Architecture — provides per-tenant observability (uptime, response time, bot/AI-crawler traffic, AEO compliance scores), AI-augmented support automation (Claude on Amazon Bedrock analyzes Tier-1 tickets and opens GitHub pull requests for a human to merge), and a content pipeline (Markdown-to-MDX with AEO validation). The client does not need an internal data or DevOps team to keep it running.
Would iSimplifyMe run this pattern inside a client’s own AWS account?
Yes. A regulated law-firm site fleet runs on the same Next.js and SST pattern inside the firm’s own AWS account, operated by iSimplifyMe, and has its own case study. This fleet program and that client-owned deployment together form the evidence base for a future AWS Migration Competency application.
How long does the per-site refactor take?
Roughly one to two weeks per site once the pattern is in place, depending on content complexity. The Apex control plane, which observes and operates the refactored sites, was the heavier lift — it has been live in production since March 2026, and each subsequent site refactor deploys onto it.
Discuss an AWS modernization for your fleet
If you are running WordPress on EC2, with or without WHM/cPanel, and paying an always-on host for sites that sit idle most of the day, we can walk through the Refactor pattern for your fleet.
- Discovery call30 min · Free · No deck — actual mechanics
- Per-site timeline1–2 weeks per site once the pattern is in place
- iSM-operatedDeploys, monitoring, AEO compliance — all on us