Leaving WordPress? First list the quiet jobs it was doing for you

People leave WordPress for good reasons. The plugin pile got too tall and every update felt like a gamble. A designer disappeared and nobody else knows how the site fits together. A static generator, a plain PHP site or an AI-assisted rebuild looks lighter and faster. A store wants a hosted platform so someone else carries the security pager.

We are not here to talk anyone out of it. We build on WordPress for a living, and we have also helped people move off it. What we keep seeing, across the communities we follow and in our own client work, is that the move itself rarely breaks a site. What breaks is the list of small jobs WordPress was doing quietly, which nobody wrote down because nobody had to.

One site owner who announced a move to a hand-built site got dozens of replies, and most of them were not "good luck" or "don't do it". They were lists: redirects, feeds, image sizes, search, spam. A company leaving for a simpler stack, an agency that handles care plans, a founder rebuilding after the original developer stopped answering, and a store owner surprised that customer passwords could not come along: different situations, same lesson. Here is how we would approach it.

Step 1: decide what you are actually leaving

"Leaving WordPress" can mean three very different things, and they carry very different amounts of risk.

• Leaving the plugin pile, not the platform. If the pain is twenty plugins with overlapping jobs, a clean rebuild on WordPress with fewer, maintained pieces may solve it at a fraction of the effort.
• Leaving the editing model. If nobody edits the site and it is really a brochure, a static site is a perfectly sensible home.
• Leaving the whole application. If people log in, buy, book, post or learn on the site, you are not moving a website, you are moving an application with users, and that is a project.

Be honest about which one you are doing before you pick a destination.

Step 2: take an inventory of the quiet jobs

Walk through this list and write down, for each item, where it lives now and where it will live after the move. "Nowhere" is a valid answer, as long as it is a decision and not a surprise.

Addresses and search engines

• Every old URL, including category, tag, author, date and attachment pages, and where each should redirect.
• The XML sitemap, and whatever was pinging search engines when content changed.
• RSS feeds that newsletters, aggregators or podcast apps still read.
• Canonical tags, meta descriptions and social preview images set per page.

Media

• The multiple image sizes and responsive image markup generated on upload.
• Old uploads that other sites hotlink or that sit in emails you already sent.

People and accounts

• User accounts and roles. Password hashes often cannot move between systems, so plan a reset flow and tell people before, not after.
• Comments, and the spam filtering that kept them readable.
• Contact forms, where submissions went, and the spam protection on them.

Scheduled and background work

• Scheduled posts, scheduled sales, expiring notices and anything else on a timer.
• Backups, uptime checks and update routines that a host or plugin was running.
• Transactional emails: receipts, password resets, notifications. Who sends them now, and from which address?

Small conveniences that people notice

• Site search.
• Previews and drafts for whoever writes content.
• Revisions, so a bad edit can be undone.
• Accessibility and language features a theme or plugin added without you thinking about it.

Most migrations we have seen go sideways missed two or three of these, not all of them. The redirects and the emails are the ones that cost real money.

Step 3: decide who owns each job after the move

The common thread in the stories we read was not technical. It was ownership. On WordPress, a plugin quietly owned the job. After the move, a person owns it, or a service does, or nobody does.

For every line in your inventory, put a name next to it. If the rebuild is AI-assisted or hand-written, that name is usually yours, for as long as the site exists. That is fine if you chose it. It is painful if you find out six months later when the sitemap stops updating.

Step 4: run both for a while

Where you can, keep the old site running on a private address after cutover. Compare traffic, form submissions and search impressions for a few weeks. If something drops, you have a working reference to check against instead of guessing what the old site used to do.

What tends to go wrong

• Redirects mapped for pages but not for posts, tags or media. Search traffic drops quietly over weeks, not on launch day.
• Forms that look fine but send nowhere. Test every form with a real submission to a real inbox.
• Members forced to reset passwords with no warning. Support load spikes and some people never come back.
• Feeds removed. Subscribers and syndication partners vanish without anyone noticing.
• A lighter stack that nobody can edit. The site is faster, but every change now waits for the one person who knows the code.

When staying is the better call

Sometimes the inventory itself answers the question. If the list of quiet jobs is long and the site has logged-in users, a cleanup on the same platform, with fewer plugins and someone clearly responsible for updates, may get you most of the relief at a fraction of the risk. If the list is short and nobody edits the site, moving off is often the right call and the inventory takes an afternoon.

Either way, writing the list is the step most people skip, and it is the cheapest insurance you can buy.

Your turn

1. If you have moved a site off WordPress, which quiet job did you only discover after launch?
2. How did you handle user accounts and passwords when they could not come with you?
3. For a site with logged-in members or customers, would you still move, or clean up on the same platform first?
4. What would you add to this inventory that most people forget?