Short answer: do not rip it out today. First establish whether the plugin is genuinely abandoned or merely finished, because a small, stable plugin can go two years without an update and be fine. Then work out which of the three risks you actually have: security exposure, compatibility decay, or data lock-in. Each has a different urgency and a different fix. Only after that do you look for a replacement, and you judge candidates on maintenance evidence you can verify yourself, not on which one ranks first in a roundup.
This article names no replacement plugins. Judging a replacement is a skill worth more than a list, and the list would be out of date by the time you read it. What follows is the criteria.
Version context (as of 2026-07-23): current stable is WordPress 7.0.2, released 2026-07-17. WordPress 7.1 is scheduled for 2026-08-19.
Step 1: is it abandoned, or just finished?
"Last updated three years ago" is the weakest signal in this whole exercise, and it is the one everybody stops at. A plugin that adds one shortcode and touches nothing else can be correct and unchanged for years. A plugin that handles logins and has not shipped in six months is a different matter.
Better evidence, all of it public on the plugin's WordPress.org directory page:
| Signal | Where to look | What it tells you |
|---|---|---|
| Support forum activity | The plugin page shows issues resolved in the last two months, and the Support tab lists open threads | Unanswered threads stacking up for months is the clearest abandonment signal there is |
| "Tested up to" | The plugin page sidebar | The author's last statement about which WordPress version they checked against. It is a claim, not a guarantee |
| Directory warning banner | Top of the plugin page | WordPress.org displays a notice when a plugin has not been tested with the last three major releases |
| Closed notice | Top of the plugin page | If the directory has closed the plugin, the page says so, with a date. Closure can mean a guideline violation, an unresolved security issue, or the author's own request |
| Changelog | Development tab | Distinguishes real maintenance from version-number bumps with no substance |
| Active installs trend | The plugin page's stats | A sharp drop usually means other people concluded something you have not yet |
A commercial plugin sold outside the directory has none of these pages. There you are checking the changelog on the vendor's own site, whether support tickets get answered, and whether your license still delivers updates. An expired license looks exactly like abandonment from inside your dashboard, and that is worth ruling out first, because it is a five-minute fix.
Step 2: which of the three risks do you have?
The word "abandoned" collapses three different problems. Sorting them is what turns panic into a schedule.
Risk 1: security exposure. Urgency: highest, and it depends entirely on what the plugin touches
An unmaintained plugin gets no patches. Whether that matters depends on its surface area. A plugin that accepts input from the public, handles file uploads, manages users or logins, or processes payments is exposed in a way that a plugin adding a Twitter icon to your footer is not.
The sharpest version of this: if the plugin has been closed in the directory for a security reason, treat it as urgent regardless of what it does. The closure notice usually means a disclosed vulnerability with no fix coming.
Risk 2: compatibility decay. Urgency: medium, and it is predictable
This is the risk that the next WordPress or PHP release breaks it. It does not usually strike out of nowhere. It strikes when you update, which means you control the timing.
You can measure it before it happens. Put the plugin on a staging copy with the newer WordPress version and see what happens. How to check plugin compatibility before updating covers the process, and what "tested up to" really tells you covers why that field is not the answer on its own.
Risk 3: data lock-in. Urgency: low today, high the day you switch
This one is invisible until you try to leave. If the plugin owns data (form submissions, event listings, member records, a custom post type, gallery structures), the migration cost is the real cost, and it grows every week you keep using it.
Find out now, while nothing is on fire, whether the plugin can export its data and in what format. That answer decides how urgent everything else is.
Step 3: your four options, honestly
Remove it. If the feature is not load-bearing, this is the cheapest correct answer, and it is more often the right one than people expect. Deactivate first, live with it deactivated for a week, then delete. Deactivating preserves settings; deleting usually destroys them, and some plugins offer an "erase data on uninstall" setting that is worth checking before you click Delete.
Replace it. The default answer, and the most work. Criteria are in the next section.
Keep it, deliberately, with compensating controls. A legitimate choice for a low-surface plugin you cannot easily replace. It means: keep it on the fixed WordPress version where it works, do not enable auto-updates around it, and keep checking whether it has been closed in the directory. This is a decision with an expiry date, so write down the date.
Rebuild the function without a plugin. For genuinely small features (a shortcode, a snippet of markup), the underlying job may now be a core feature. WordPress has absorbed a great deal of what plugins used to do, including sitemaps, lazy loading and much of what page builders were needed for.
How to judge a replacement without anybody selling you one
The criteria, in the order that actually predicts whether you will be doing this again in two years:
- Recent, substantive changelog entries. Not "compatibility bump". Fixes, with descriptions.
- Support threads getting answered, including the awkward ones. Read three open threads before installing anything.
- A stated compatibility position. Tested-up-to at or near current WordPress, and a declared minimum PHP version.
- An export path out. Ask the leaving question before you arrive. If the replacement cannot export its own data, you are choosing your next lock-in.
- More than one maintainer, or a company behind it. Single-author plugins are not bad, but they carry a single point of failure, and that is exactly the failure you are recovering from.
- A migration path from what you have. Some plugins ship importers for common alternatives. That is worth more than any feature comparison.
- Scope that matches your need. A plugin doing ten things you do not want is ten times the surface area and ten times the reasons it will break.
What is not a criterion: install count alone (popular plugins get abandoned too), star ratings (they age badly), and appearing in somebody's list of the best plugins.
Doing the switch safely
Back up files and database first, and confirm you can restore, not just that the backup exists. Then, in order:
- Export whatever data the old plugin owns, and open the export file to confirm it contains something.
- Do the swap on a staging copy if you have one. Run both plugins side by side there if they will tolerate it, so you can compare output.
- Install the replacement and configure it before deactivating the old one, where the two do not conflict. This shortens the window where the feature is missing from your live site.
- Deactivate, do not delete, the old plugin. Leave it deactivated for a couple of weeks. Deactivated plugins do not run, but their settings survive, and that is your undo.
- Check the pages that used the feature. Old shortcodes from a removed plugin render as visible text on the page, which is the most common cosmetic aftermath of a swap. Search your content for the shortcode name.
- Delete the old plugin once you are confident. A deactivated plugin's files still sit on your server, and unmaintained code on disk is still code on disk.
If the swap goes wrong, the symptom usually looks like the ones in plugin not working after a WordPress update, and the same diagnosis order applies.
What this cannot solve
If the plugin is the site (a membership platform, a store, a booking system), this is not a plugin swap, it is a migration project, and treating it as an afternoon's work is how sites end up half-moved. Budget for it, do it on staging, and keep the old system readable until the new one has run a full billing or booking cycle.
And there is no way to make an abandoned plugin safe by leaving it deactivated but installed. Deactivated plugin files are still on the server. If you have decided against it, delete it.
Whatever you replace it with, the routine that catches the next one is the same one that catches everything else: the pre-update checklist, run before each update, and a periodic look at the WordPress 7.x guide for site owners to see what core now does that your plugins used to.
FAQ
How long without an update means a WordPress plugin is abandoned?
There is no fixed number. WordPress.org itself flags plugins not tested with the last three major releases, which is a reasonable trigger to investigate. Treat the flag as a prompt to check support activity and the changelog, not as a verdict.
Is it dangerous to keep using an abandoned plugin?
It depends on what it touches. A plugin handling logins, uploads, public form input or payments is a real exposure. A plugin that outputs static markup in one place is a much smaller one. Danger tracks surface area, not the age of the last release.
What does it mean when a plugin is closed on WordPress.org?
The directory has removed it from public listing, and the page states the date. Reasons include guideline violations, unresolved security issues, or an author request. You keep the copy you already installed, but you will receive no further updates through the directory.
Can I fix an abandoned plugin myself?
If it is licensed under the GPL, as directory plugins are, you may modify it or hire a developer to. This is a real option for small, critical plugins, and it means you now own the maintenance. Never edit plugin files directly on a live site: work on a copy, and keep the original untouched.
Will deleting the plugin delete my data?
Sometimes. Many plugins leave their database tables and options behind on uninstall, and some offer a setting that erases everything. Export first, then delete, and keep the export somewhere off the server.
