November 10th, 2026 | AI
By: Justin Phelan
PHP2Shell Forced My Hand on Drupal 7. An AI Agent Did the Rest.
On October 21, the PHP project shipped emergency patches for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, which researchers nicknamed PHP2Shell. The fixes went out in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Wiz demonstrated unauthenticated attacks against WordPress, Drupal, and Joomla sites, because the flaws live in PHP itself and every application running on top of it inherits them.
If your server runs an older PHP branch, no patch is coming.
I had several Drupal 7 sites sitting on exactly that kind of server, running PHP 7.2. PHP 7.2 stopped receiving security fixes in 2019. Drupal 7 reached end of life in January 2025. These sites had been running fine for years, and the owners liked them. PHP2Shell turned "we should deal with that eventually" into "this has to move now."
So I moved them to Statamic. An AI agent did nearly all of the work.
Why old sites stay old
Everyone who owns a Drupal 7 site has heard the warnings. Most of them stayed put anyway, and the reason was always money.
There has never been an in-place upgrade from Drupal 7 to modern Drupal. Getting to Drupal 10 or 11 means building a new site and migrating the content into it. Moving to a different CMS means the same thing. Either way, the estimate covered the same list: model every content type again, rebuild the theme template by template, write and debug migration scripts, then QA the result page by page. Weeks of developer time, so the client could end up with the site they already had.
For a church or small nonprofit with a couple of people updating content, that was a hard check to write. Paying a vendor like HeroDevs or Tag1 for Drupal 7 extended security support was the cheaper way to buy time. Plenty of owners did neither and hoped.
That cost is what has changed.
What the agent did
I pointed a Claude agent at a legacy Drupal 7 codebase and its database and asked it to rebuild the site in Statamic. By my estimate, it did 99% of the work.
It started by reading the old site the way a developer would. It inventoried the content types and their fields, the taxonomy vocabularies, the menus, and the Views that powered listing pages and blocks. It read the theme's template files to understand how each content type rendered and where the regions sat.
Then it rebuilt the structure in Statamic. Drupal content types became Statamic collections, each with a blueprint carrying the same fields. Vocabularies became taxonomies. Views became collection listings in the templates, with the same filters, sorting, and pagination the old pages had.
The theme came across too, and it came across better. The agent rebuilt it on Tailwind CSS, keeping the layout and look the owners were used to while cleaning up a decade of accumulated CSS. Same site, visually. Much less code underneath.
For the content, it wrote a custom Artisan command. Statamic runs on Laravel, so a migration can be a normal console command that queries the Drupal 7 tables directly (node, the field_data_* tables, taxonomy_term_data, file_managed, url_alias) and writes each record out as a Statamic entry. It copied uploaded files into Statamic's asset containers and carried the old URL aliases over, so existing links and search rankings kept working.
The part I kept for myself was judgment: reviewing what the agent built, spot-checking migrated content against the old site, deciding what to retire, and handling the cutover. That work should stay with a person. It also takes hours, where the rebuild used to take weeks.
Why this is new
Developers have used AI to write code for a few years now. Writing a migration script was never the hard part, though. The hard part was holding an entire legacy site in view at once: how a field on one content type feeds a View, which renders through a template override, which depends on a module nobody remembers installing.
With Claude Opus 5.5 and Claude Fable, the agent keeps track of all of it across a long task. It reads the old system, plans the new one, builds it, migrates into it, and checks its own work against the source. Earlier models could help with pieces of a migration. These can carry the whole job.
When the rebuild is cheap, the old math stops working. The question used to be "can we afford to migrate?" Now it's "where should this site live?"
Why Statamic
So why did I choose to migrate these sites from Drupal 7 to Statamic rather than, say, Drupal 11? I love Statamic as a CMS for several reasons.
Content lives in flat Markdown and YAML files, so the whole site, content included, sits in version control. There's no database to keep patched for a small brochure or ministry site, though Statamic can use one when a project needs it. It runs on Laravel, so it gets a modern PHP release schedule and a framework with an active security team. It ships with Tailwind CSS by default. The control panel is clean enough that editors who struggled with Drupal 7's admin pick it up quickly.
To be clear about PHP2Shell: Statamic sites needed the PHP patch too, like every PHP site. The difference is that a Statamic 6 site runs on a supported PHP version, so the patch existed and applying it was routine. A Drupal 7 site on PHP 7.2 had nothing to apply.
The same logic applies to WordPress, for a different reason. WordPress core is fine, I guess. The main trouble is the plugin culture around it, which pushes a typical site toward dozens of plugins from different vendors, each with its own update schedule and its own way of breaking after an update. If you are tired of plugin conflicts and white screens after routine updates, the cost of leaving is now low enough to take seriously.
When Drupal is still the better home
Statamic handles more than people expect. Plenty of private schools, small colleges, and medium-sized universities run their sites with a central web team and a handful of departmental editors, and Statamic suits that setup well. Roles and permissions cover most editorial arrangements, and multi-site support lets separate schools or programs share one install. When a site grows past what flat files handle comfortably, its entries can move into a database without a rebuild.
Drupal 11 still earns its place at the far end of that range. If a site spans dozens of departments with their own editors and approval workflows, or it's really an application with deep relational data and integrations into student systems, Drupal's depth is worth the extra complexity. An agent can do a Drupal 7 to Drupal 11 rebuild just as well, and the cost drop applies there too.
The right platform depends on who maintains the site after launch. A school with two content editors and a marketing coordinator needs something simple to run. A university web team with a dozen editors might be well served by Statamic or might need Drupal's governance tools, depending on how they work. We can help you compare the options and make that decision.
What it still costs
Some costs don't go away; good, reliable hosting, for example. A Statamic Pro license is needed for multiple editor accounts and content moderation. Someone qualified has to review the agent's work, because an agent can faithfully migrate a broken thing and a person needs to catch that. Decisions about what content to keep and what to retire belong to the site owner.
The weeks of rebuild labor that made migration a budget conversation are gone, though. If you have been holding onto an old site because you liked it and couldn't justify paying to get the same thing back, that trade-off has changed. Keeping it on an unsupported stack is now the expensive option.
Thinking about moving an old site?
If you're on Drupal 7, or you're worn out by WordPress plugin problems, and you mostly want to keep the site you have with a cleaner theme and an easier way to edit content, we can move it to Statamic and host it on our servers. we offer managed hosting, which means we take care of making sure your site stays up to date and secure, and are here to help when any issues arise. Send us the URL and we'll tell you honestly what the move involves, including whether Statamic is the right destination or whether your site belongs somewhere else.
Justin Phelan
Full Stack Developer