Shimira ITWordPress & PHP to Next.js migration
Tired of patching PHP? Move the site to Next.js and keep the rankings.
On 21 October 2026, PHP shipped emergency fixes for two critical flaws that let an attacker run code on a server without logging in. Every WordPress, Drupal, and Joomla site in the world needed the same patch on the same afternoon, and the ones that didn't get it were exploited or taken offline as a precaution. If that week cost you sleep, a weekend, or customers, the first thing to do is patch. The second is to ask whether you want to be in that position again.
We move WordPress and other PHP sites to Next.js, and we do it the slow, careful way: every URL mapped and redirected, every title and description carried over, the content moved into a CMS your editors can actually use, and a side-by-side crawl before launch so nothing Google indexed goes missing. We'll also tell you plainly when a migration is the wrong call, because it sometimes is. If the site is already down or compromised, start with project rescue instead; migration is for after the fire is out.
What you get
What a migration includes
Migration audit and content inventory
A full crawl of the current site: every URL, template, form, plugin, redirect, and integration listed, with a keep-rebuild-or-drop call for each. You find out how big the job really is before you commit to it.
URL-for-URL redirects and metadata parity
Each old URL maps to a new one or a 301, titles and descriptions move across unchanged unless you ask us to improve them, and structured data, canonicals, and sitemaps are rebuilt. Losing rankings is the main reason people fear migrations, and it's avoidable.
A CMS your team can use
Content moved into a headless CMS (Sanity, Payload, or Contentful), into Markdown in Git for small sites, or kept in WordPress behind a login as a headless source. Editors keep editing; the public site stops being a PHP application.
Plugins replaced by decisions
Forms, search, analytics, caching, SEO, and security plugins each become either a built feature, a hosted service, or nothing at all. Caching and security plugins usually become nothing, because a pre-rendered site needs neither.
Launch, monitoring, and a quiet first month
Cutover with DNS planned in advance, Search Console watched daily for a month, 404s and ranking shifts handled as they appear, and documentation for whoever maintains the site next.
- Next.js
- React
- TypeScript
- Sanity
- Payload CMS
- PostgreSQL
- Vercel
Why a pre-rendered site is safer, and why it's not magic
The honest version of the security argument, because the dishonest one gets repeated a lot.
- What actually changes. A WordPress page is assembled by PHP on every request: the interpreter, the database, the theme, and every plugin are all running and all reachable from the public internet. A pre-rendered Next.js page is a file. There is no interpreter waiting for a request to exploit, so the October flaws, and the long list before them, have nothing to land on.
- What doesn't. Next.js is not immune. In December 2025, React2Shell (CVE-2025-55182) was a critical remote-code-execution flaw in React Server Components that affected Next.js apps using them. Anything that runs code on a server can have a flaw like that. The difference is how much of your site runs code on a server at all, and for a content site the answer can be close to none.
- Where the CMS goes. If editors keep using WordPress as a headless source, that WordPress still needs patching; it just stops being the thing visitors hit. Putting it behind a login or an IP allow-list shrinks the exposed surface to the people who should be there. Moving to a hosted CMS removes the PHP entirely.
- Speed is the other half. Pages served as files from a CDN load in a fraction of the time a PHP stack manages, without a caching plugin, and Core Web Vitals usually improve without anyone tuning them. That's the part your visitors notice; the security is the part they don't.
The October 2026 flaws are CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older are out of upstream support. If your host hasn't confirmed one of those versions, that comes before anything on this page.
Proof
We've shipped this.
A statically-generated Next.js site whose organic clicks grew about 4× in three months, measured in Google Search Console. The same build approach is what a migrated site lands on: fast pages, clean URLs, metadata and structured data on every page, and a sitemap Google trusts.
Worth knowing
Should you migrate at all?
A migration is weeks of work and a real SEO risk if it's done carelessly. It earns its cost when several of these are true:
- The site is a marketing or content site: pages, posts, landing pages, a blog, a few forms. That's the case where the public site can become files and the PHP can go away entirely.
- You've been bitten by PHP or plugin patching more than once, or the October 2026 release took the site offline.
- Page speed is costing you: Core Web Vitals are red, the caching plugin fights the other plugins, and the hosting bill keeps climbing to compensate.
- The theme or plugins are abandoned, and nobody wants to touch the site because something might break.
- Your developers already work in React and the WordPress site is the one thing they can't maintain.
- You want the site to be one part of a larger product (a portal, an app, a members' area) rather than a separate island.
When we'd say no: a WooCommerce store with dozens of plugins doing real work, a team that lives in the WordPress editor and doesn't want to learn another, or a small brochure site on good managed hosting where the host patches for you. In those cases we'll say so in the audit and suggest hardening instead.
How it runs
How a migration runs
The order matters: inventory first, redirects before design, and a crawl comparison before anyone touches DNS.
- 01
Audit & inventory
1 weekFull crawl and Search Console export. Every URL, template, form, plugin, and integration listed with a keep-rebuild-or-drop call. You get a written scope, a CMS recommendation, and one fixed price, or a recommendation not to migrate.
- 02
Content model & CMS
1–2 weeksPost types, taxonomies, and page templates mapped into a content model. Content migrated with a script, not by hand, and checked against the original. Editors get the new CMS early so they can tell us what's wrong while it's cheap to fix.
- 03
Build
2–8 weeksTemplates rebuilt in Next.js, forms and search wired to hosted services, redirects written and tested, metadata and structured data generated per page. Weekly demos on a staging URL.
- 04
Crawl comparison & cutover
1 weekOld and new sites crawled side by side: URLs, titles, descriptions, canonicals, and status codes compared line by line. Only when the diff is clean do we move DNS, submit the new sitemap, and switch monitoring on.
- 05
First month
30 days after launchSearch Console checked daily, 404s and dropped queries fixed as they appear, and a written handover of the whole setup. Most migrations show rankings holding or improving by the end of it.
Timelines & pricing
Honest ranges, not a lump sum.
| Site type | Timeline | Typical investment |
|---|---|---|
| Migration audit | 1 week | $1.5K – $3K fixed |
| Marketing site (up to ~30 pages, forms) | 3–5 weeks | $6K – $12K |
| Content site (blog, hundreds of posts, headless CMS) | 6–10 weeks | $12K – $25K |
| Complex (members' area, custom plugins, commerce) | 3–5 months | $25K – $60K+ |
Figures are indicative; the audit turns them into one fixed price for your site. Hosting after launch is usually cheaper than managed WordPress, since there is no PHP or database to keep warm. For the ongoing side, see the software maintenance cost guide, and for what the current site is costing you in patching and firefighting, the audit puts a number on that too.
A low-risk start
Send us the URL. Get a written answer on whether to move.
If the site is unpatched today, we'll tell you how to confirm that first. The audit can wait a day; the patch can't.
How you work with us
Three ways to engage.
Fixed price
Prototypes from $7,500
Production MVPs from $25,000
You know what you need built. We scope it, quote one price, and deliver against it, no meter running.
- One agreed price, agreed before we start
- Milestone-based payments tied to what you can see
- Change requests priced openly, never assumed
Time & materials
from $28 / hour
Blended ~$32; senior specialists to ~$45
For work that changes as you learn. You pay for the hours spent, see exactly where they go, and can steer week to week.
- Billed on real, logged hours, reviewed with you
- Reprioritise or change direction any sprint
- Start small, scale the team as it proves out
Dedicated team
from $2,800 / month
Per developer, full-time, see the rate card
Developers who work only on your product, full-time, as an extension of your team, the offshore model most of our long-term clients settle into.
- The same people, month after month
- Your tools, your standups, your roadmap
- Roughly half the loaded cost of a local hire
Full rate card and what's included on the pricing page.
Why Shimira IT
What you're actually buying.
An honest go or no-go
The audit can come back as “stay on WordPress and harden it.” Sometimes that's the right answer, and we'd rather say it than sell a migration that shouldn't happen.
Rankings treated as the deliverable
Redirects, metadata parity, and a crawl diff before cutover are the job, not an afterthought. We build and grow Next.js sites ourselves and measure them in Search Console.
Editors who can still edit
A migration that leaves your team unable to publish has failed. The CMS is chosen with them, and they get it before launch.
Nothing left to patch at 2 a.m.
When the public site is files on a CDN, the next PHP emergency is someone else's week.
Questions
Before you get in touch.
Not as a language, no. Any server-side code can have a critical flaw, and Next.js has had them (React2Shell, CVE-2025-55182, in late 2025). What changes is the attack surface: a pre-rendered content site has no interpreter, database, or plugins reachable from the public internet, so there is almost nothing for a flaw to run against. WordPress exposes all of those on every request.
Not if the migration is done properly. Rankings are lost when URLs change without redirects, metadata is dropped, or pages quietly disappear. We map every URL, carry titles and descriptions across unchanged, rebuild structured data and sitemaps, and crawl both sites side by side before cutover. Some short-term movement is normal; a sustained loss is a sign something was skipped.
Three options, chosen in the audit. A hosted headless CMS (Sanity, Contentful) or a self-hosted one (Payload) gives editors a modern editor with previews. Markdown in Git suits small sites run by technical teams. Keeping WordPress as a headless source behind a login lets editors keep the interface they know, though that WordPress still has to be patched.
Each one becomes a decision. Forms go to a hosted form service or a small API route. Search goes to a hosted search index. Analytics stays as a script. SEO plugins become code that generates metadata per page. Caching and security plugins are usually not needed at all, since a pre-rendered site is already cached and has far less to secure.
Sometimes, and we'll be honest about when it's a bad idea. A store that leans on many WooCommerce extensions is often better kept on WordPress and hardened. A store with a simple catalogue can move to Next.js with a headless commerce backend. The audit tells you which you have.
The audit is $1,500–$3,000 fixed. A marketing site of up to about 30 pages typically runs $6,000–$12,000; a content site with hundreds of posts and a headless CMS $12,000–$25,000; a complex site with a members' area, custom plugins, or commerce $25,000–$60,000+. The audit replaces these ranges with one fixed price for your site.
Yes. Drupal, Joomla, Laravel marketing sites, and hand-built PHP sites follow the same process: inventory, content model, redirects, build, crawl comparison, cutover. Custom PHP applications with real business logic are a different conversation and usually a rebuild rather than a migration; see custom software development.
Not sure what you need yet? That's the usual starting point.
Tell us the problem in your own words. We'll scope it with you and put the plan in writing, free, and yours to keep either way.